1.5 Описание атрибутов
На основании таблицы сущностей (см.табл.1.1) и каталога задач и запросов (см.п.1.3), а также путём опроса экспертов и изучения документальных источников,/11,12/ выделим все необходимые атрибуты.
В таблице (табл.1.2) приводится описание атрибутов:
Таблица 1.2
Описание атрибутов
Наименование атрибута | Тип Значения | Диапазон Значений | Возм-ть принимать неопределённые значения | Метод контроля достоверности |
1 | 2 | 3 | 4 | 5 |
Код товара | Числовой | Диапазон | Нет | <0 And >=100000 |
Наименование | Текстовый | - | Нет | <=60 симв |
Вес брутто (гр) | Числовой | Диапазон | Нет | <0 |
Вес нетто (гр) | Числовой | Диапазон | Нет | <0 |
Цена за единицу | Денежный | - | Нет | <0 |
Вид упаковки | Текстовой | - | Нет | <=20 симв |
Номер договора | Числовой | Диапазон | Нет | <0 And <=10000000 |
Дата | Дата\время | Диапазон | Нет | [1..31],[1..12], [1996..2025] |
Сумма | Денежный | - | Нет | <0 |
Код заказчика | Числовой | Диапазон | Нет | <0 And <=10000000 |
Наименование заказчика | Текстовый | - | Нет | <=60 симв |
ФИО руководителя | Текстовый | - | Нет | <=60 симв |
Адрес | Текстовый | - | Нет | <=80 симв |
Тел\Факс | Текстовый | - | Нет | <=40 симв |
Номер накладной | Числовой | - | Нет | <0 And <=10000000 |
Дата накладной | Дата\время | Диапазон | Нет | [1..31],[1..12], [1996..2025] |
Сумма по накл | Денежный | - | Нет | <0 |
Код поставщика | Числовой | Диапазон | Нет | <0 And <=10000000 |
Наименование поставщика | Текстовый | - | Нет | <=60 симв |
ФИО Руководителя | Текстовый | - | Нет | <=60 симв |
Адрес | Текстовый | - | Нет | <=80 симв |
Тел\Факс | Текстовый | - | Нет | <=40 симв |
Номер счета | Числовой | Диапазон | Нет | <0 And <=10000000 |
Дата | Дата\время | Диапазон | Нет | [1..31],[1..12], [1996..2025] |
Сумма | Денежный | - | Нет | <0 |
НДС | Денежный | - | Нет | <0 |
Сумма к оплате | Денежный | - | Нет | <0 |
Количество | Числовой | Диапазон | Нет | <0 And <=10000 |
Диапазоны значений определяются из анализа документов, так же как и ограничения на длину текста. Нужно также сказать, что для осуществления взаимосвязи между атрибутами-ключами различных связанных таблиц необходимо совпадение по типу данных и ограничению по длине строки. Эта проблема решается путём унификации всех сходных атрибутов-ключей.
1.6 Концептуальная модель
На рис. 1.1 представлена графическая схема концептуальной модели определением всех связей и первичных ключей.
рис. 1.1
Графическое представление концептуальное модели наглядно поясняет предметную область.
1.7 Описание связей
1. Многие ко многим. Один поставщик поставляет много товара и одно
наименование товара может поставлять много поставщиков.
2. Один ко многим. Один поставщик может заключить много договор на
поставку товара с оптовой базой и в одном договоре может участвовать
только один поставщик
3. Один ко многим. С одним поставщиком может заключаться много счетов и
определенный счет может быть только у одного поставщика.
4. Многие ко многим. В одной накладной много товара и одно наименование
товара может быть во многих накладных.
5. Один ко многим. В одной накладной может быть несколько счетов.
6. Один ко многим. Заказчик создает много накладных.
7. Многие ко многим. В одном договоре много товара и одно наименование товара может встречаться в нескольких договорах.
8. Многие ко многим. Один заказчик заказывает партию товара и одно наименование товара может быть заказано многими заказчиками.
9. Один ко многим. С одним заказчиком может заключаться много счетов и только каждый счет соответствует одному заказчику.
10. Один ко многим. Счет создается на партию товара.
11. Один к одному. Договор может содержать только один счет.
1.8 Итоги построения концептуальной модели
В концептуальной модели мы смогли выделить из всей предметной области набор сущностей и установить связи между ними. Для каждой сущности определили первичный ключ и атрибуты.
2. РЕЛЯЦИОННАЯ МОДЕЛЬ БАЗЫ ДАННЫХ
2.1 Выбор логической модели
Хранимые в базе данные имеют определённую логическую структуру, то есть модель. Различают следующие основные модели представления данных в базе данных:
- иерархическую
- сетевую
- реляционную
- объектно-ориентированную
В иерархической модели данные представляются в виде древовидной иерархической структуры./3/ Достоинством данной модели является возможность реализовать очень быстрый поиск, когда условия запроса соответствуют иерархии в схеме БД, однако при работе с данными со сложными логическими связями иерархическая модель оказывается слишком громоздкой.
В сетевой модели данные организуются в виде произвольного графа./4/ Достоинством этой модели является высокая скорость поиска и возможность адекватно представлять данные для решения множества задач в самых различных предметных областях. Высокая скорость поиска основывается на классическом способе реализации сетевой модели - на основе списков. Недостатком сетевой модели является жесткость структуры и высокая сложность ее организации.
Кроме того, существенным недостатком иерархической и сетевой моделей является то, что структура данных задается на этапе проектирования БД и не может быть изменена при организации доступа к данным.
Реляционная модель получила свое название от английского термина relation (отношение) и была предложена в 1970-х годах сотрудником фирмы IBM Эдгаром Коддом. Реляционная БД представляет собой совокупность таблиц, связанных отношениями. Разница между таблицей в привычном смысле и понятием отношения заключается в том, что в отношении нет порядка - это неупорядоченное множество записей. Порядок определяется не отношением, а конкретной выборкой из отношения. Связь между таблицами существует на логическом уровне и определяется предметной областью. Практически связь между таблицами устанавливается путем использования логически связанных данных в разных таблицах.
Для работы с реляционными СУБД используется стандартизированный язык структурированных запросов SQL.
Достоинствами реляционной модели данных являются простота, гибкость структуры, удобство реализации на компьютере, высокая стандартизованность и использование математического аппарата реляционной алгебры и реляционного исчисления.
К недостаткам можно отнести атомарность, ограниченность и предопределенность набора возможных типов данных. Это затрудняет использование реляционных моделей для некоторых современных приложений. Названная проблема решается расширением реляционных моделей в объектно-реляционные.
В объектно-реляционной модели отдельные записи база данных представляются в виде объектов. Между записями базы данных и функциями их обработки устанавливаются взаимосвязи с помощью механизмов, подобных соответствующим средствам в объектно-ориентированных языках программирования. Объектно-ориентированные модели сочетают особенности сетевой и реляционной моделей и используются для создания крупных БД со сложными структурами данных.
Перейти к иерархической модели данных сложно, ввиду сложности реализации сложных связей через древовидные структуры (хотя реализация части сущностей и связей иерархии (см.п.1.6) через данную логическую модель достаточно просто). Гораздо больше подходит сетевая модель данных, однако мы выбираем реляционную модель, потому что
· представление данных в виде двухмерных таблиц проще, чем виде списков;
· большинство современных СУБД поддерживают реляционную модель данных, что облегчает нам выбор СУБД;
· реляционная модель проста, обладает гибкой структурой, удобна для реализации на компьютере.
Выбор объектно-реляционной модели решил бы проблемы с реализацией связей, однако возникли бы неоправданные проблемы с созданием математического представления и выбором СУБД./4/ Принимая во внимание всё вышесказанное, делаем выбор – реляционная модель данных.
... электронного обмена данными, — и эти инвестиции должны рассматриваться в контексте общей маркетинговой стратегии. ГЛАВА 2. функционирование Центра закупки компьютерной техники 2.1 Общая характеристика центра закупки компьютерной техники (на примере ООО "Аверс") Торговое оптовое розничное предприятие ООО "Аверс" - одно из крупнейших предприятий на территории Республики Хакасия, ...
... 576 с. 15. Круглова, Т. Э. Создание на базе областной детской библиотеки г. Пскова музея романа В.А. Каверина «Два капитана» // Публичные библиотеки. Пути взаимодействия: библиотеки-музеи. Вып. 5. — Новоуральск, 2001. — С. 25—30. 16. Литературный музей в библиотеке: проблемы моделирования: программа спецкурса для студентов библ.-информ. ф-та / КГАКИ; сост. Т.В. Абалимова. — Казань, 1998. — 30 ...
... продукции, создавать новые рынки, расширять производство, изменять организационные структуры управления, обеспечивая их адаптивность к основным изменениям характеристики рынка и поведения потребителя. Использование автоматизированной системы продажи сотовых телефонов, которая включает в себя создание базы данных клиентов, дает возможность отслеживать потребности и приоритеты в выборе телефона ...
... тестирования; модель должна иметь привлекательный вид Однако главной задачей проектирования было создание модели коммуникативного класса для проведения дистанционного обучения, имеющую правильный педагогический дизайн и основанную на современных информационных технологиях. 1.2 Средство разработки модели В настоящее время информационные технологии внедряются во всё новые и новые области ...
0 комментариев