СУБД Предприятия

      Выходные  данные — результаты запросов и  отчеты, выводимые на экран либо на печатающее устройство.

 

  3 КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ СУБД 

      3.1 Описание схемы «объект-отношение» 

      Схема изображена на рисунке 3.1.

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Рисунок 3.1 — Схема «объект-отношение» 

      На  схеме (см. рисунок выше) существует 4 объекта. Рассмотрим их подробнее.

      Свойствами  объекта «Предприятие» являются: название предприятия, город, тип предприятия, дата открытия. Одно предприятие может состоять из большого количества цехов. А один цех одновременно может относиться только к одному предприятию. Следовательно, объект «Предприятие» связывается с объектом «Цех» связью 1:∞.

      Свойства  объекта «Цех»: название цеха, дата открытия, дата последней реконструкции, количество рабочих. В каждом цехе изготовляется  большое количество изделий, но изделие каждого типа может одновременно относиться только к одному цеху, таким образом, объект «Цех» связан с объектом «Изделие» связью 1:∞.

      Объект  «Изделие» содержит свойства: название изделия, тип изделия.

      Для ведения ежемесячного плана выпуска  изделий мы можем использовать информацию о многих изделиях. Каждое изделие содержит много планов (по месяцам). Связь между объектами «Изделие» и «План выпуска» будет ∞:∞. Свойствами этой связи будут: цена изделия в текущем месяце, количество выпущенных изделий.

      Объект «План выпуска» содержит свойства: месяц и год. 

      3.2 Обоснование выбора модели данных 

      3.2.1 Иерархическая модель данных 

      В иерархической модели связи между  данными описывают с помощью  упорядоченного графа (или дерева). Тип является составным. Он включает в себя подтипы («поддеревья»), каждый из которых, в свою очередь, является типом «дерево». Каждый из элементарных типов, включенных в тип «дерево», является простым или составным типом «запись».

      Таким образом, иерархическая модель данных представляет собой упорядоченную совокупность экземпляров типа «дерево» (деревьев), содержащих экземпляры типа «запись» (записи).

      В соответствии с определением типа «дерево», можно заключить, что между предками и потомками автоматически поддерживается контроль целостности связей. Основное правило контроля целостности формулируется следующим образом: потомок не может существовать без родителя, а у некоторых родителей может не быть потомков. Механизмы поддержки целостности связей между записями различных деревьев отсутствуют.

      Пример  реализации иерархической модели данных для разрабатываемой БД представлен  на рисунке 3.2. 

            

            1)  

        

        

 
 
 
 

      

      

               
 
 
 
 

Рисунок 3.2 – Пример иерархической модели данных

      Корневым  является тип «Предприятие», который в свою очередь подтип: «Цех». «Цех» имеет подтип «Изделие», который в свою очередь имеет подтип «План выпуска».

      К достоинствам иерархической модели данных относят эффективное использование памяти ЭВМ и высокое быстродействие основных операций над данными. Данная модель данных удобна для работы с иерархически упорядоченной информацией.

      Недостатком этой модели является высокая избыточность и сложные логические связи. Одна запись БД – это совокупность деревьев. Через эту структуру нельзя построить отношение N:N (многие ко многим). Очевидна громоздкость обрабатываемой информации, сложность в понимании для конечного пользователя. Иерархическая модель не имеет механизма поддержки целостности данных. Также любые изменения в структуре модели требуют изменение программы. 

      3.2.2 Сетевая модель данных 

      Сетевая модель позволяет отображать разнообразные  взаимосвязи элементов данных в виде произвольного графа, обобщая тем самым иерархическую модель данных.

      Данная  модель данных состоит из набора записей  и набора соответствующих связей. В отличие от иерархической модели в сетевой запись-потомок может иметь произвольное число записей-предков (сводных родителей).

      Схема сетевой модели данных для данной БД показана на рисунке 3.3. Типы связей здесь обозначены надписями на соединяющих типы записей линиях.

      

      

        
 

      

      

      

        

Рисунок 3.3 — Пример сетевой модели данных 

      Анализируя  схему, видим, что все элементы связаны  друг с другом. Любой элемент может быть выражен через другие элементы. Минус подобной связи: на формирование типов связи не накладываются особые ограничения, что приводит при выполнении основных операций над данными к негативным для проектируемой БД ситуациям. Например, в дополнительной таблице появятся записи, которые не имеют родительских записей в основной таблице.

      Недостатком сетевой модели данных является высокая  сложность и жесткость схемы БД, построенной на ее основе, а также сложность для понимания и выполнения обработки информации в БД обычным пользователем. Кроме того, в данной модели данных ослаблен контроль целостности связей вследствие допустимости установления произвольных связей между записями. Таким образом, для нашей БД данную модель данных применять нежелательно.

      Достоинством  сетевой модели данных является возможность  эффективной реализации по показателям затрат памяти и оперативности. В сравнении с иерархической, сетевая модель предоставляет большие возможности в вопросе допустимости образования произвольных связей. 

      3.2.3 Реляционная модель данных 

      Реляционная модель данных некоторой предметной области представляет собой набор отношений (двумерных таблиц), изменяющихся во времени.

      В общем случае можно считать, что  реляционная БД включает одну или  несколько таблиц, объединенных смысловым  содержанием, а также процедурами контроля целостности и обработки информации в интересах решения некоторой прикладной задачи. Например, при использовании СУБД Microsoft Access в файле БД наряду с таблицами хранятся и другие объекты базы: запросы, отчеты, формы, макросы и модули.

      Достоинство реляционной модели данных заключается в простоте, понятности и удобстве физической реализации на ЭВМ. С помощью одной таблицы удобно описывать простейший вид связей между данными, а именно деление одного объекта, информация о котором храниться в таблице, на множество подобъектов, каждому из которых соответствует строка или запись таблицы. Физическое размещение данных в реляционных базах на внешних носителях легко осуществляется с помощью обычных файлов. Проблемы же эффективности обработки данных этого типа оказались технически вполне разрешимыми.

      Основными недостатками реляционной модели являются следующие: отсутствие стандартных средств идентификации отдельных записей и сложность описания иерархических и сетевых связей.

      Для проектируемой БД реляционная модель представлена на рисунке 3.4.

      Состоит модель из девяти объектов: «Предприятие», «Тип», «Город», «Цех», «Тип изделия», «Изделие». Связи между объектами устанавливаются с помощью ключей:

      — «Код типа» связывает объекты  «Тип» (первичный ключ) и «Предприятие» (внешний ключ);

      — «Код города» связывает объекты «Город» (первичный) и «Предприятие» (внешний);

      — «Код предприятия» связывает объекты  «Предприятие» (первичный) и «Цех» (внешний);

      — «Код цеха» связывает объекты  «Цех» (первичный) и «Изделие» (внешний);

      — «Код типа изделия» связывает объекты «Тип изделия» (первичный) и

      «Изделие» (внешний);

      — «Код изделия» связывает объекты  «Изделие» (первичный) и «План выпуска» (внешний);

      — «Код месяца» связывает объекты  «Месяц» (первичный) и «План на месяц» (внешний);

      — «Код плана на месяц» связывает объекты «План на месяц» (первичный) и «План выпуска» (внешний).