Проектирование базы данных - Программирование, компьютеры и кибернетика курсовая работа

Семантическое моделирование данных. Основные понятия модели Entity-Relationship. Построение инфологической модели в виде диаграммы "Таблица-связь". Проектирование физической модели базы данных. Разработка формы заставки, главной, вторичных кнопочных форм.


посмотреть текст работы


скачать работу можно здесь


полная информация о работе


весь список подобных работ


Нужна помощь с учёбой? Наши эксперты готовы помочь!
Нажимая на кнопку, вы соглашаетесь с
политикой обработки персональных данных

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Дисц.: Математические основы баз данных
Разрабатываемая база данных предназначена для автоматизации учета заказа материалов у поставщиков, работы со сведениями о расчетах с поставщиками и для формирования учетных документов.
Разрабатываемая система может быть использована любой организацией, которая закупает любые материалы у сторонних организаций.
Пользователями разрабатываемой системы могут быть бухгалтерия, расчетный сектор, отдел снабжения и прочие организационные подразделения, занимающиеся учетом поступления материалов и расчетами с поставщиками. Таким образом, в структуре организации разрабатываемая база данных будет использована в аппарате управления.
База данных будет разработана в СУБД MS Access, как наиболее удобной и популярной. Содержание создаваемой базы данных не повлияет на её структуру и является примерным.
История систем автоматизации проектирования баз данных (CASE-средств) началась с автоматизации процесса рисования диаграмм, проверки их формальной корректности, обеспечения средств долговременного хранения диаграмм и другой проектной документации. Конечно, компьютерная поддержка работы с диаграммами для проектировщика БД очень полезна. Наличие электронного архива проектной документации помогает при эксплуатации, администрировании и сопровождении базы данных. Но система, которая ограничивается поддержкой рисования диаграмм, проверкой их корректности и хранением, напоминает текстовый редактор, поддерживающий ввод, редактирование и проверку синтаксической корректности конструкций некоторого языка программирования, но существующий отдельно от компилятора. Кажется естественным желание расширить такой редактор функциями компилятора, и это действительно возможно, поскольку известна техника компиляции конструкций языка программирования в коды целевого компьютера. Но коль скоро имеется четкая методика преобразования концептуальной схемы БД в реляционную схему, то почему бы не выполнить программную реализацию соответствующего «компилятора» и не включить ее в состав системы проектирования баз данных?
Эта идея, естественно, показалась разумной производителям CASE-средств проектирования БД. Подавляющее большинство подобных систем, представленных на рынке, обеспечивает автоматизированное преобразование диаграммных концептуальных схем баз данных, представленных в той или иной семантической модели данных, в реляционные схемы, специфицированные чаще всего на языке SQL.
У читателя может возникнуть вопрос, почему в предыдущем предложении говорится про «автоматизированное», а не про «автоматическое» преобразование? Все дело в том, что в типичной схеме SQL-ориентированной БД могут содержаться определения многих объектов (ограничений целостности общего вида, триггеров и хранимых процедур и т. д.), которые невозможно сгенерировать автоматически на основе концептуальной схемы. Поэтому на завершающем этапе проектирования реляционной схемы снова требуется ручная работа проектировщика.
Еще раз обратите внимание на то, какой ход рассуждений привел нас к выводу о возможности автоматизации процесса преобразования концептуальной схемы БД в реляционную схему. Если создатели семантической модели данных предоставляют методику преобразования концептуальных схем в реляционные, то почему бы не реализовать программу, которая производит те же преобразования, следуя той же методике? Зададимся теперь другим, но, по существу, схожим вопросом. Если создатели семантической модели данных предоставляют язык (например, диаграммный), используя который проектировщики БД на основе исходной информации о предметной области могут сформировать концептуальную схему БД, то почему бы не реализовать программу, которая сама генерирует концептуальную схему БД в соответствующей семантической модели, используя исходную информацию о предметной области? Хотя нам не известны коммерческие CASE-средства проектирования БД, поддерживающие такой подход, экспериментальные системы успешно существовали. Они представляли собой интегрированные системы проектирования с автоматизированным созданием концептуальной схемы на основе интервью с экспертами предметной области и последующим преобразованием концептуальной схемы в реляционную.
Как правило, CASE-средства, автоматизирующие преобразование концептуальной схемы БД в реляционную, производят реляционную схему базы данных в третьей нормальной форме. Нормализация более высокого уровня усложняет программную реализацию и редко требуется на практике.
Наконец, третья возможность, которую следует упомянуть, хотя она еще не вышла (или только выходит, а может быть, так никогда и не выйдет) за пределы исследовательских и экспериментальных проектов, - это работа с базой данных в семантической модели, т. е. СУБД, основанные на семантических моделях данных. При этом снова рассматриваются два варианта: обеспечение пользовательского интерфейса на основе семантической модели данных с автоматическим отображением конструкций этого интерфейса в реляционную модель данных (это задача примерно того же уровня сложности, что и автоматическая компиляция концептуальной схемы базы данных в реляционную схему) и прямая реализация СУБД, основанная на какой-либо семантической модели данных. Многие авторитетные специалисты полагают, что ближе всего ко второму подходу объектно-ориентированные СУБД, чьи модели данных по многим параметрам близки к семантическим моделям (хотя в некоторых аспектах они более мощны, а в некоторых - более слабы).
Широкое распространение реляционных СУБД и их использование в самых разнообразных приложениях показывает, что реляционная модель данных достаточна для моделирования предметных областей. Однако проектирование реляционной базы данных в терминах отношений на основе кратко рассмотренного нами механизма нормализации часто представляет собой очень сложный и неудобный для проектировщика процесс.
При этом проявляется ограниченность реляционной модели данных в следующих аспектах:
· Модель не предоставляет достаточных средств для представления смысла данных. Семантика реальной предметной области должна независимым от модели способом представляться в голове проектировщика. В частности, это относится к упоминавшейся нами проблеме представления ограничений целостности.
· Для многих приложений трудно моделировать предметную область на основе плоских таблиц. В ряде случаев на самой начальной стадии проектирования проектировщику приходится производить насилие над собой, чтобы описать предметную область в виде одной (возможно, даже ненормализованной) таблицы.
· Хотя весь процесс проектирования происходит на основе учета зависимостей, реляционная модель не предоставляет каких-либо средств для представления этих зависимостей.
· Несмотря на то, что процесс проектирования начинается с выделения некоторых существенных для приложения объектов предметной области ("сущностей") и выявления связей между этими сущностями, реляционная модель данных не предлагает какого-либо аппарата для разделения сущностей и связей.
Далее мы кратко рассмотрим некоторые черты одной из наиболее популярных семантических моделей данных - модель "Сущность-Связи" (часто ее называют кратко ER-моделью).
На использовании разновидностей ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Ченом (Chen) в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в системах CASE, поддерживающих автоматизированное проектирование реляционных баз данных. Среди множества разновидностей ER-моделей одна из наиболее развитых применяется в системе CASE фирмы ORACLE. Ее мы и рассмотрим. Более точно, мы сосредоточимся на структурной части этой модели.
Основными понятиями ER-модели являются сущность, связь и атрибут.
Сущность - это реальный или представляемый объект, информация о котором должна сохраняться и быть доступна. В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности. При этом имя сущности - это имя типа, а не некоторого конкретного экземпляра этого типа. Для большей выразительности и лучшего понимания имя сущности может сопровождаться примерами конкретных объектов этого типа.
Каждый экземпляр сущности должен быть отличим от любого другого экземпляра той же сущности (это требование в некотором роде аналогично требованию отсутствия кортежей-дубликатов в реляционных таблицах).
Связь - это графически изображаемая ассоциация, устанавливаемая между двумя сущностями. Эта ассоциация всегда является бинарной и может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). В любой связи выделяются два конца (в соответствии с существующей парой связываемых сущностей), на каждом из которых указывается имя конца связи, степень конца связи (сколько экземпляров данной сущности связывается), обязательность связи (т.е. любой ли экземпляр данной сущности должен участвовать в данной связи).
Связь представляется в виде линии, связывающей две сущности или ведущей от сущности к ней же самой. При это в месте "стыковки" связи с сущностью используются трехточечный вход в прямоугольник сущности, если для этой сущности в связи могут использоваться много (many) экземпляров сущности, и одноточечный вход, если в связи может участвовать только один экземпляр сущности. Обязательный конец связи изображается сплошной линией, а необязательный - прерывистой линией.
Как и сущность, связь - это типовое понятие, все экземпляры обеих пар связываемых сущностей подчиняются правилам связывания.
Как и в реляционных схемах баз данных, в ER-схемах вводится понятие нормальных форм, причем их смысл очень близко соответствует смыслу реляционных нормальных форм. Заметим, что формулировки нормальных форм ER-схем делают более понятным смысл нормализации реляционных схем. Мы приведем только очень краткие и неформальные определения трех первых нормальных форм.
В первой нормальной форме ER-схемы устраняются повторяющиеся атрибуты или группы атрибутов, т.е. производится выявление неявных сущностей, "замаскиро-ванных" под атрибуты.
Во второй нормальной форме устраняются атрибуты, зависящие только от части уникального идентификатора. Эта часть уникального идентификатора определяет отдельную сущность.
В третьей нормальной форме устраняются атрибуты, зависящие от атрибутов, не входящих в уникальный идентификатор. Эти атрибуты являются основой отдельной сущности.
Мы остановились только на самых основных и наиболее очевидных понятиях ER-модели данных. К числу более сложных элементов модели относятся следующие:
· Подтипы и супертипы сущностей. Как в языках программирования с развитыми типовыми системами (например, в языках объектно-ориентированного программирования), вводится возможность наследования типа сущности, исходя из одного или нескольких супертипов. Интересные нюансы связаны с необходимостью графического изображения этого механизма.
· Связи "many-to-many". Иногда бывает необходимо связывать сущности таким образом, что с обоих концов связи могут присутствовать несколько экземпляров сущности (например, все члены кооператива сообща владеют имуществом кооператива). Для этого вводится разновидность связи "многие-со-многими".
· Уточняемые степени связи. Иногда бывает полезно определить возможное количество экземпляров сущности, участвующих в данной связи (например, служащему разрешается участвовать не более, чем в трех проектах одновременно). Для выражения этого семантического ограничения разрешается указывать на конце связи ее максимальную или обязательную степень.
· Каскадные удаления экземпляров сущностей. Некоторые связи бывают настолько сильными (конечно, в случае связи "один-ко-многим"), что при удалении опорного экземпляра сущности (соответствующего концу связи "один") нужно удалить и все экземпляры сущности, соответствующие концу связи "многие". Соответствующее требование "каскадного удаления" можно сформулировать при определении сущности.
· Домены. Как и в случае реляционной модели данных бывает полезна возможность определения потенциально допустимого множества значений атрибута сущности (домена).
Эти и другие более сложные элементы модели данных "Сущность-Связи" делают ее существенно более мощной, но одновременно несколько усложняют ее использование. Конечно, при реальном использовании ER-диаграмм для проектирования баз данных необходимо ознакомиться со всеми возможностями.
В нашей лекции мы немного подробнее разберем только один из упомянутых элементов - подтип сущности.
Сущность может быть расщеплена на два или более взаимно исключающих подтипа, каждый из которых включает общие атрибуты и/или связи. Эти общие атрибуты и/или связи явно определяются один раз на более высоком уровне. В подтипах могут определяться собственные атрибуты и/или связи. В принципе подтипизация может продолжаться на более низких уровнях, но опыт показывает, что в большинстве случаев оказывается достаточно двух-трех уровней.
Сущность, на основе которой определяются подтипы, называется супертипом. Подтипы должны образовывать полное множество, т.е. любой экземпляр супертипа должен относиться к некоторому подтипу. Иногда для полноты приходится определять дополнительный подтип ПРОЧИЕ.
Пример: Супертип ЛЕТАТЕЛЬНЫЙ АППАРАТ
Как полагается это читать? От супертипа: ЛЕТАТЕЛЬНЫЙ АППАРАТ, который должен быть АЭРОПЛАНОМ, ВЕРТОЛЕТОМ, ПТИЦЕЛЕТОМ или ДРУГИМ ЛЕТАТЕЛЬНЫМ АППАРАТОМ. От подтипа: ВЕРТОЛЕТ, который относится к типу ЛЕТАТЕЛЬНОГО АППАРАТА. От подтипа, который является одновременно супертипа: АЭРОПЛАН, который относится к типу ЛЕТАТЕЛЬНОГО АППАРАТА и должен быть ПЛАНЕРОМ или МОТОРНЫМ САМОЛЕТОМ.
Иногда удобно иметь два или более разных разбиения сущности на подтипы. Например, сущность ЧЕЛОВЕК может быть разбита на подтипы по профессиональному признаку (ПРОГРАММИСТ, ДОЯРКА и т.д.), а может - по половому признаку (МУЖЧИНА, ЖЕНЩИНА).
Шаг 1. Каждая простая сущность превращается в таблицу. Простая сущность - сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.
Шаг 2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут.
Шаг 3. Компоненты уникального идентификатора сущности превращаются в первичный ключ таблицы. Если имеется несколько возможных уникальных идентификатора, выбирается наиболее используемый. Если в состав уникального идентификатора входят связи, к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (этот процесс может продолжаться рекурсивно). Для именования этих столбцов используются имена концов связей и/или имена сущностей.
Шаг 4. Связи многие-к-одному (и один-к-одному) становятся внешними ключами. Т.е. делается копия уникального идентификатора с конца связи "один", и соответствующие столбцы составляют внешний ключ. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи - столбцам, не допускающим неопределенные значения.
Шаг 5. Индексы создаются для первичного ключа (уникальный индекс), внешних ключей и тех атрибутов, на которых предполагается в основном базировать запросы.
Шаг 6. Если в концептуальной схеме присутствовали подтипы, то возможны два способа:
· для каждого подтипа - отдельная таблица (б)
При применении способа (а) таблица создается для наиболее внешнего супертипа, а для подтипов могут создаваться представления. В таблицу добавляется по крайней мере один столбец, содержащий код ТИПА; он становится частью первичного ключа.
При использовании метода (б) для каждого подтипа первого уровня (для более нижних - представления) супертип воссоздается с помощью представления UNION (из всех таблиц подтипов выбираются общие столбцы столбцы супертипа).
Необходимо разработать базу данных для системы учета поступления материалов в организацию и учета расчетов с поставщиками этих материалов.
Предполагается, что база данных должна хранить информацию о поставщиках, материалах и закупках. Также база данных должна хранить информацию и о самой организации, в которой она будет использована.
Для примерного заполнения базы данных, предположим, что она будет использована в магазине расходных материалов для компьютеров и оргтехники.
Магазин является связующим звеном в цепочке производитель-пользователь. Его основной деятельностью является перепродажа материалов, которые он закупает у производителей или оптовых поставщиков.
В разрабатываемой базе данных необходимо реализовать учет поступающих товаров и учет расчетов за него на основе документов, которые использует организация для совершения подобных операций. Упрощенная схема документооборота между поставщиком и покупателем следующая

Рисунок 2.1 Упрощенная схема документооборота между поставщиком и покупателем
Поставщик выставляет счет покупателю за предоплату материалов. Покупатель выписывает платежное поручение своему банку, с целью оплаты счета. После чего происходит передача материалов от поставщика покупателю вместе с приходной накладной и счет-фактурой. Выписки из банков носят информативный характер, сообщая о проведенных операциях с расчетным счетом его владельцу.
Таким образом, входящими документами для покупателя являются:
- выписка о состоянии р/с (от банка);
Выписку из банка, о списании с расчетного счета денежных средств, можно исключить из рассмотрения, так как она является подтверждением платежного поручения.
В итоге можно сделать вывод, что разрабатываемая система должна вбирать в себя информацию из документов: «счет», «приходная накладная» и «счет фактура». На выходе система должна формировать документ «платежное поручение», а также прочие отчетные документы о сведениях в базе данных.
Основными характеристиками рассматриваемой организации - магазина по продаже расходных материалов - будут следующими:
- Наименование организации (НаимОрг): ООО «Техномир»;
- Адрес организации (АдрОрг): 685000, Россия, Магадан, ул. Пролетарская 12;
- Телефон организации (ТелОрг): 953813;
- Факс организации (ФаксОрг): 953814;
- ФИО руководителя (РукОрг): Петров Петр Петрович;
- Гл. бухгалтер (ГБухОрг): Петрова Анастасия Петровна.
- Идентификационный номер налогоплательщика (ИНН): 5551231245;
- Код причины постановки на учёт (КПП): 984567123;
- Общероссийский классификатор предприятий и организаций (ОКПО):12458795;
- Расчетный счет ( Р/С): 40227810311164421001;
- Наименование Банка (НаимБанк): Магаданское ОСБ №5448;
- Банковский Идентификационный Код (БИК): 454841451;
- Корреспондентский счет (К/С): 30000103111199445510;
1. Счет. Он содержит следующие данные:
- реквизиты поставщика-получателя: наименование, адрес, телефон, ИНН, КПП, номер р/с, название банка, город банка, номер корр/с, БИК, руководитель предприятия поставщика, главный бухгалтер предприятия поставщика;
- реквизиты покупателя-плательщика: наименование;
- перечень товара: наименование товара, единица измерения (ед. изм.), количество, цена, сумма (*);
Бланк документа «Счет» представлен в приложении 1.
- реквизиты поставщика: наименование, ИНН, адрес, телефон, р/с, банк, БИК, корр/с, ОКПО, руководитель предприятия поставщика, главный бухгалтер предприятия поставщика;
- реквизиты плательщика: наименование, ИНН, адрес, телефон, р/с, банк, БИК, корр/с, ОКПО;
- перечень товара: товар (наименование, код), ед. изм. (наименование, код по ОКЕИ), вид упаковки, количество (в одном месте, мест, штук), масса брутто, количество (масса нетто), цена, сумма без НДС (*), НДС (ставка, сумма (*)), сумма с учетом НДС (*).
- Итого: масса нетто(*), сумма без учета НДС(*), сумма НДС (*), сумма с учетом НДС (*);
Бланк документа «Приходная накладная» представлен в приложении 2.
- реквизиты продавца: наименование, адрес, ИНН, КПП, руководитель предприятия поставщика, главный бухгалтер предприятия поставщика;
- реквизиты покупателя: наименование, адрес, ИНН, КПП;
- номер платежного поручения покупателя;
- дата платежного поручения покупателя;
- перечень товара: наименование товара, ед. изм. наименование, количество, цена, сумма без НДС (*), НДС ставка, сумма НДС (*), сумма с учетом НДС (*), страна происхождения, номер таможенной декларации;
- всего к оплате: сумма НДС (*), сумма с учетом НДС (*).
Бланк документа «Счет-фактура» представлен в приложении 3.
Атрибуты, помеченные (*) являются результатом расчетов между другими атрибутами этого же документа.
Выходным документом является платежное поручение. Оно содержит следующую информацию:
- реквизиты нашей организации: наименование, ИНН, р/с, наименование банка, город банка, БИК, корр/с, руководитель, главный бухгалтер;
- реквизиты поставщиков: наименование, ИНН, р/с, наименование банка, город банка, БИК, корр/с, руководитель, главный бухгалтер;
- назначение платежа: номер счета, дата счета, сумма, сумма НДС.
В дополнении к указанному документу, можно создать разного рода отчеты, которые будут описывать содержимое базы данных.
Бланк документа «Платежное поручение» представлен в приложении 4.
Дополнительные отчеты, которые будут реализованы в базе данных:
1. Отчет «Сведения о поставщиках», содержит следующие атрибуты:
- реквизиты поставщика: наименование;
- общая сумма, уплаченная поставщику за поставленный товар;
- реквизиты нашей организации: наименование, ИНН, КПП, Адрес, Телефон, Руководитель, Главный бухгалтер, БИК, р/с.
- наименование товара, единицы измерения;
- общая стоимость закупленного товара;
- реквизиты нашей организации: наименование, ИНН, КПП, Адрес, Телефон, Руководитель, Главный бухгалтер, БИК, р/с.
Программное приложение должно предоставлять следующие возможности по работе с разрабатываемой базой данных:
- добавление новых данных в каждую таблицу;
- редактирование уже введенных данных;
- осуществлять быстрое нахождение необходимых сведений о субъектах, объектах или документации по ключевым полям данных элементов;
- предоставлять возможность формирования и печати отчетных и выходных документов.

Рисунок 2.2 Функциональная схема разрабатываемого программного приложения
2. Один счет оплачивается одним платежным поручением;
3. Грузоотправителем и грузополучателем являются поставщик и покупатель соответственно;
5. Реквизиты покупателя и поставщиков постоянны;
6. Стоимость одного экземпляра материала является постоянной.
Инфологическая или информационная модель (схема данных) и ее описание предполагает моделирование входных, промежуточных и результатных информационных массивов предметной области и их характеристика. Необходимо детально освятить как на основе входных документов и нормативно справочной информации происходит обработка с использованием массивов оперативной информации и формирования выходных данных.
Информационная модель разработанной базы данных представлена на рисунке 2.3
Схема данных позволяет установить связи между таблицами и обеспечить целостность данных. Из этой схемы видно, что главными таблицами является таблицы «Товары» и «Заказы», которым подчиняются остальных 5 таблиц. Каждая из них имеет код, по которому осуществляется связь с главными таблицами.
Удачная разработка базы данных обеспечивает простоту ее поддержания. Данные следует сохранять в таблицах, причем каждая таблица должна содержать информацию одного типа, например, сведения о поставщиках. Тогда достаточно будет обновить конкретные данные, такие как адрес, только в одном месте, чтобы обновленная информация отображалась во всей базе данных.
Одним из наиболее сложных этапов в процессе проектирования базы данных является разработка таблиц, так как результаты, которые должна выдавать база данных (отчеты, выходные формы и др.) не всегда дают полное представление о структуре таблицы.
Главными информационными объектами в рассматриваемой предметной области являются наша организация и поставщики. Ниже представлено их описание:
1) Сущность НАША ОРГАНИЗАЦИЯ. Характеризуется следующими атрибутами:
- Идентификационный номер налогоплательщика (ИНН);
- Код причины постановки на учёт (КПП);
- Наименование организации (НаимОрг);
- Общероссийский классификатор предприятий и организаций (ОКПО);
- Банковский Идентификационный Код (БИК);
2) Сущность ПОСТАВЩИКИ. Характеризуется следующими атрибутами:
- Идентификационный номер налогоплательщика (ИНН);
- Код причины постановки на учёт (КПП);
- Наименование организации (НаимОрг);
- Общероссийский классификатор предприятий и организаций (ОКПО);
- Банковский Идентификационный Код (БИК);
Следующая группа данных, которая фигурирует во всех входящих документах, это поставляемые материалы. Следует разграничить постоянные и не постоянные сведения. Так количество и итоговая стоимость закупаемых материалов зависят от сделки. Наименование и характеристики остаются, неизменны при любой сделке.
3) Сущность ТОВАРЫ. Характеризуется следующими атрибутами:
- Код единицы измерения (КодЕдИзм);
- Наименование единицы измерения (НаимЕдИзм);
- Страна происхождения товара (СтранТов);
- Номер таможенной декларации (ДеклТов);
- Количество в одном месте (КолВМест).
Последний вид сведений из документов, который следует проанализировать, это сведения о закупках. Однако сначала выберем из документов их собственные сведения и оформим их в отдельные сущности.
4) Сущность СЧЕТА. Характеризуется следующими атрибутами:
- Дата составления счета (ДатаСчет).
5) Сущность ПЛАТЕЖНЫЕ ПОРУЧЕНИЯ. Характеризуется следующими атрибутами:
- Дата составления поручения (ДатаПоруч);
6) Сущность СЧЕТ-ФАКТУРЫ. Характеризуется следующими атрибутами:
- Дата составления счет-фактуры (ДатаСчетФ).
7) Сущность ТОВАРНЫЕ НАКЛАДНЫЕ. Характеризуется следующими атрибутами:
- Номер товарной накладной (НомТовНак);
- Дата составления товарной накладной (ДатаТовНак).
Последние сущности, которые объединяют все документы в одно целое это ЗАКУПАЕМЫЙ ТОВАР и ЗАКУПКИ. Сущность ЗАКУПАЕМЫЙ ТОВАР выступает в роли связующего звена для сущностей ЗАКУПКИ и ТОВАРЫ, обеспечивая связь многие ко многим.
Нормализацией называется формальная процедура, в ходе которой атрибуты данных группируются в таблицы, а таблицы группируются в базу данных (БД).
Результатами анализа проведенного в предыдущем разделе стали 9 сущностей: НАША ОРГАНИЗАЦИЯ, ПОСТАВЩИКИ, ТОВАРЫ, СЧЕТА, ПЛАТЕЖНЫЕ ПОРУЧЕНИЯ, СЧЕТ-ФАКТУРЫ, ТОВАРНЫЕ НАКЛАДНЫЕ, ЗАКУПАЕМЫЙ ТОВАР, ЗАКУПКИ. Каждая сущность характеризуется группой атрибутов, часть из которых может дублироваться в других сущностях. Для оптимизации данных необходимо провести процедуру нормализации, которая выполняется поэтапно.
Первая нормальная форма (1НФ). Для нее требуется, чтобы таблица была плоской и не содержала повторяющихся групп. У плоской таблицы есть только две характеристики - длина (количество записей или строк) и ширина (количество полей или столбцов). Такая таблица не должна содержать ячеек, включающих несколько значений. Т.е. в одну ячейку не должны помещаться несколько атрибутов.
Для приведения сущностей к таблицам первой нормальной форме, необходимо исключить дублирование множества характеристик между двумя сущностями, путем присвоения ключевых атрибутов тем сущностям, которые их не имеют. Так, например, для упоминания поставщика в сущности ЗАКУПКИ нет необходимости дублировать характеристики сущности ПОСТАВЩИКИ, достаточно внести в атрибуты сущности ПОСТАВЩИКИ ключевое поле: Код поставщика (КодПостав). А в сущности ЗАКУПКИ заменить атрибут «Характеристики поставщика» на «Код поставщика», и в дальнейшем связать две этих сущности через созданное поле. Аналогичным образом по необходимости добавляются ключевые атрибуты к другим сущностям.
Для второй нормальной формы (2НФ) требуется, чтобы все поля таблицы зависели от первичного ключа, то есть, чтобы первичный ключ однозначно определял запись и не был избыточен. Значение первичного ключа в таблице БД должно быть уникальным, т.е. в таблице не должно существовать двух и более записей с одинаковым значением первичного ключа. Те поля, которые зависят только от части первичного ключа, должны быть выделены в составе отдельных таблиц.
В частности выделение в отдельную сущность информацию о банках позволило исключить дублирование в сущности ПОСТАВЩИКИ.
Сущность БАНКИ. Характеризуется следующими атрибутами:
- Банковский Идентификационный Код (БИК);
Для третьей нормальной формы (ЗНФ) требуется, чтобы все не ключевые столбцы таблицы зависели от первичного ключа таблицы, но были независимы друг от друга. Для этого требуется, чтобы таблицы были приведены к 1НФ и 2НФ.
Сущность ТОВАРЫ не соответствует третьей нормальной форме, так как имеет атрибут зависимый от другого атрибута - Наименование единицы измерения от Кода единицы измерения. Для приведения к третьей нормальной форме из сущности товары была выделена еще одна сущность: ЕДИНИЦЫ ИЗМЕРЕНИЯ.
Сущность ЕДИНИЦЫ ИЗМЕРЕНИЯ. Характеризуется следующими атрибутами:
- Код единицы измерения (КодЕдИзм);
- Наименование единицы измерения (НаимЕдИзм);
В итоге, благодаря нормализации были выделены еще 2 сущности: БАНКИ и ЕДИНИЦЫ ИЗМЕРЕНИЯ. В конечном счете, общие число сущностей стало равно 11. В результате нормализации были добавлены ключевые атрибуты, которые обеспечат связь между сущностями. Данные связи продемонстрированы в следующем разделе.

Рисунок 2.4 Инфологическая модель в виде диаграммы «Таблица связь»
Реляционная база данных представляет собой множество взаимосвязанных таблиц, каждая из которых содержит информацию об объектах определенного типа.
Наиболее удобной и популярной системой управления базой данных (СУБД), которая позволит реализовать все необходимые задачи по разработке базы данных и программного приложения является продукт компании Microsoft - Access.
Microsoft Access является настольной СУБД реляционного типа. Достоинством Access является то, что она имеет очень простой графический интерфейс, который позволяет не только создавать собственную базу данных, но и разрабатывать простые и сложные приложения. В отличие от дру
Проектирование базы данных курсовая работа. Программирование, компьютеры и кибернетика.
Дипломная работа: Электрические нагрузки ремонтно-механического цеха
Дипломная работа по теме Современные особенности управления системой образования на примере Челябинской области
Сочинение по теме Портрет бабушки в повести М. Горького "Детство"
Курсовая Работа На Тему Финансовые Ресурсы Страны
Хадзарагова Елена Александровна Автореферат Докторской Диссертации
Реферат Возрастная Периодизация Скачать
Критерии Курсовой Работы По Госту 2022
Реферат: Український правопис
Колесных Пар Реферат
Дипломная работа по теме Политический портрет Д. Мазарини
Реферат по теме Показатели эффективности инвестиционного проекта
Реферат По Ботанике На Тему Лекарственные Растения
Сочинение 9.3 Дружба
Принципы Альтернативного Разрешения Споров Реферат
Реферат по теме Социализация как индикатор межнационального общения
Реферат: Расчет освещения рабочего места оператора ЭВМ. Скачать бесплатно и без регистрации
Проблемы Космоса Реферат
Реферат: Конструирование ПЛИС. Скачать бесплатно и без регистрации
Курсовая Работа На Тему Формирование Умения Решения Квадратных Уравнений В 8 Классе
Реферат: Русь бесприютная
Основи підприємницької та управлінської діяльності - Маркетинг, реклама и торговля методичка
Жан Батист Поклен - Литература презентация
Графический метод решения задач линейного программирования - Программирование, компьютеры и кибернетика задача