Проектирование базы данных

Автор работы: Пользователь скрыл имя, 28 Марта 2011 в 11:52, курсовая работа

Описание работы

В состав базы данных «Предприятие» входят следующие объекты данных:
объект «Организации»;
объект «Виды деятельности»;
объект «Товары и услуги»;
объект «Запросы».

Файлы: 1 файл

проектирование БД.doc

— 356.50 Кб (Скачать файл)

    Все аномалии, выявленные в первой нормальной форме, во второй нормальной форме устранены. Теперь можно вводить и удалять данные раздельно по организациям, видам деятельности, товарам, услугам, оперативной информации.

    Рассмотрим  теперь вторую нормальную форму на предмет определения аномалий.

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

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

  1. аномалия обновления – в том случае, если данный товар или услуга, уже связанный с каким-либо предприятием, связывается с другим предприятием, то цена может быть другой. Возникает неопределенность – или каждый раз просматривать отношение, представленное в табл. 9, и каждый раз вручную изменять вид, или нарушать непротиворечивость данных, когда в некоторых кортежах цена будет изменена, а в некоторых - нет;
  2. аномалия удаления (тип 1) – при удалении данных о предприятии также удаляются данные о товаре или услуге, и если этот товар или услуга были связаны только с этим предприятием, то возможна потеря данных о них;
  3. аномалия удаления (тип 2) – при удалении данных о товаре или услуге также удаляются данные о предприятии, и если это предприятие было связано только с этим товаром или услугой, то возможна потеря данных о нем.

    Тот факт, что пока какой-либо  товар  или услуга не связаны с каким-либо предприятием, невозможно указать цену, аномалией не является.

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

1.2.3. ТРЕТЬЯ НОРМАЛЬНАЯ  ФОРМА

    Для того, чтобы перейти от второй нормальной формы к третьей, надо из отношения  «Товары и услуги», представленного  в табл. 9, выделить информацию о ценах в отдельное отношение, которому присвоить имя «Цены». В самом отношении «Товары и услуги» останутся данные только о наименованиях товаров и услуг, а в отношении «Цены» будут присутствовать данные только о ценах на товары и услуги по организациям. Отношение «Товары и услуги» представлено в табл. 12 и рис. 9, отношение «Цены» представлено в табл. 13 и рис. 10.

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

    Таблица 12.

    Товары  и услуги

        Номер товара, услуги Наименование  товара, услуги
 

    

    

      
 
 

    Рис.9. Графическое представление отношения  «Товары и услуги».

    Таблица 13.

    Цены

        Номер товара, услуги Номер Цена
         
 
 

    

    

      

    

      

       

      

    Рис.10. Графическое представление отношения  «Цены».

    Первичным ключом отношения «Товары и услуги»  является атрибут «Номер товара, услуги», первичным ключом отношения «Цены» являются атрибуты «Номер товара, услуги»  и «Номер».

    Рассмотрим  аномалии, выявленные в ходе анализа  первой нормальной формы:

  1. аномалия обновления – можно связывать любые товары или услуги с любыми предприятиями и проставлять любые необходимые цены;
  2. аномалия удаления (тип 1) – при удалении данных о предприятии не происходит потеря данных о товаре или услуге;
  3. аномалия удаления (тип 2) – при удалении данных о товаре или услуге не происходит потеря данных о предприятии.

    Итак, все аномалии, выявленные в ходе анализа второй нормальной формы, устранены. В результате нормализации получены семь отношений, находящихся в третьей  нормальной форме. Эти отношения представлены в табл. 7, табл. 8, табл. 10, табл. 11, табл. 12, табл. 13  и на рис. 4, рис. 5, рис. 7, рис. 8, рис. 9, рис. 10.

    На  этом процесс нормализации закончен.

1.3. ГРАФИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ  КОНЦЕПТУАЛЬНОЙ МОДЕЛИ  ДАННЫХ

    Определим взаимосвязи между отношениями «Организации», «Виды деятельности», «Товары и услуги», «Цены», «Оперативная информация», «Виды деятельности организации». Исходными данными для этого являются следующие пункты:

  1. одно предприятие может заниматься несколькими видами деятельности;
  2. одно предприятие может иметь несколько производимых товаров и услуг;
  3. одно предприятие может иметь несколько запросов оперативной информации или не иметь их совсем;
  4. один и тот же вид деятельности может принадлежать нескольким предприятиям;
  5. один и тот же товар может выпускаться несколькими предприятиями и по разным ценам;
  6. каждый отдельный запрос оперативной информации принадлежит только одному конкретному предприятию.

    Взаимосвязи, построенные на основании этой информации, представлены на рис. 11.  

    

    

    

    

    

    

      

    

      
 

Рис.11. Взаимосвязи  между объектами.

    Отношения «Организации», «Виды деятельности», «Товары и услуги», «Цены», «Оперативная информация», «Виды деятельности организации» после нормализации представлены следующим  образом:

  1. Номер – Название, Страна, Адрес, Телефон, № квартала регистрации, Год регистрации, № квартала  снятия с регистрации, Год снятия с регистрации;
  2. Шифр – Наименование вида деятельности;
  3. Номер товара, услуги – Наименование товара, услуги;
  4. Номер товара, услуги * Номер – Цена;
  5. Номер запроса * Номер – Оперативная информация;
  6. Номер * Шифр.

    В результате имеем следующее:

  1. Каждое отношение, первичный ключ которого содержит один элемент данных, представляет объект.
  2. Каждое отношение, первичный ключ которого содержит два элемента данных, являющихся первичными ключами других отношений, представляет взаимосвязи между объектами. В том случае, если отношение с двумя ключевыми элементами данных содержит неключевой элемент данных, отсутствующий в других отношениях, то это отношение представляет объект.

    На  основании этого создадим графическое  представление концептуальной модели данных. Результат представлен на рис. 12. Двойные стрелки соответствуют связи типа «ко многим». 

    Номер – Название, Страна, Адрес, Телефон, № квартала регистрации, Год регистрации, № квартала  снятия с регистрации, Год снятия с регистрации;

    

      

    

    

      
 

    

    

    

    

    

      
 
 
 

    Рис.12. Графическое представление концептуальной модели данных.

2. ПРОЕКТИРОВАНИЕ ЛОГИЧЕСКОЙ  МОДЕЛИ ДАННЫХ  ДЛЯ СЕТЕВОЙСУБД

    При проектировании логической модели в  качестве исходных данных возьмем концептуальную модель, представленную на рис. 12.

2.1. ВЫВОД ОБОБЩЕННОЙ  СЕТЕВОЙ МОДЕЛИ

    В концептуальной модели на рис. 12 прямоугольники представляют узлы, а стрелки –  взаимосвязи между ними. На первом уровне находятся узлы «Виды деятельности», «Товары и услуги», «Организации». На втором уровне находятся узлы «Цены», «Виды деятельности организации» «Оперативная информация». Узлы первого уровня являются исходными, узлы второго уровня – порожденными. Для узла «Цены» исходными узлами являются «Организации» и «Товары и услуги». Для узла «Виды деятельности организации» исходными узлами являются «Организации» и «Виды деятельности». Для узла «Оперативная информация» исходным узлом является «Организации».

    Транзитивность  отсутствует, так как все связи  направлены только вертикально с одного уровня на другой, горизонтальных связей нет, уровней всего два (см. рис. 12).

    При проектировании логической модели данных для иерархической СУБД на основе концептуальной модели необходимо, чтобы  у каждого порожденного узла был  только один исходный.

    В нашем случае все исходные и порожденные  узлы – отношения в третьей  нормальной форме.

    Рассмотрим  группу узлов «Органиации», «Виды  деятельности», «Виды деятельности организации».

    В данном случае узел «Виды деятельности»  можно сделать исходным, а узлы «Органиации» и «Виды деятельности организации» объединить. В результате получается конструкция, показанная на рис. 13.

    

      
 

    

      

      
 

      
 
 

    Рис.13. Группа узлов «Органиации», «Виды  деятельности», «Виды деятельности организации». 

    Рассмотрим  группу узлов «Организации», «Товары и услуги», «Цены».

    В данном случае узел «Организации» можно  сделать исходным, а узлы «Товары  и услуги» и «Цены» объединить. В результате получается конструкция, показанная на рис. 14.

    Для группы узлов «Организации» и  «Оперативная информация» никаких преобразований производить не нужно.

      

    

    

    

      
 
 
 

    Рис.14. Группа узлов «Организации», «Товары  и услуги», «Цены». 

    Для получения полной логической модели объединим группы узлов, представленные на рис. 13, рис. 14. Узел «Организации + Виды деятельности организации» (рис. 13) базируется на узле «Организации», поэтому при создании полной логической модели эти узлы объединим в один узел. Полученная логическая модель представлена на рис. 15. 
 
 
 
 
 

    

Информация о работе Проектирование базы данных