Проектирование и разработка базы данных для предприятия "Статус"

Размещено на http://www.allbest.ru

Министерство сельского хозяйства Российской Федерации

Департамент научно-технологической политики и образования

Федеральное государственное образовательное учреждение

высшего профессионального образования

«Красноярский государственный аграрный университет»

Институт Менеджмента и Информатики

Кафедра «Информационных систем

и технологий в экономике»

Курсовой проект

на тему

Проектирование и разработка базы данных для предприятия ООО«Статус»

Выполнила студентка 3 курса,

группы ПИ-33, специальности 080800.62 - «Прикладная информатика»

Болтус Екатерина Юрьевна

Руководитель Титовская Наталья Викторовна

Красноярск 2012



Содержание

Введение

1. Анализ объекта исследования

1.1 Характеристика объекта исследования

1.2 Комплекс задач, решаемых объектом исследования

1.3Текущий уровень использования ИТ

1.4 Предложения по модернизации информационных технологий

1.5 Выбор методов и средств решения задач, подлежащих автоматизации

1.6 Определение общих требований к проектируемой системе

2. Проектирование программных средств информационной системы

2.1 Декомпозиция проектируемой системы

2.2 Определение состава и назначения подсистем проектируемой информационной системы

2.3 Проектирование и реализация подсистем

2.3.1 Проектирование и реализация подсистемы хранения

2.3.2 Проектирование и реализация подсистемы ввода

2.3.3 Проектирование и реализация подсистемы вывода

2.3.4 Проектирование и реализация подсистемы обработки

Заключение

Библиографический список

Приложения

база данный информационный подсистема



Введение

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

Программное обеспечение, предназначенное для работы с базами данных, называется система управления базами данных (СУБД). СУБД используются для упорядоченного хранения и обработки больших объемов информации.

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

просматривать,

пополнять,

изменять,

искать нужные сведения,

делать любые выборки,

осуществлять сортировку в любом порядке.

Базы данных являются одним из основных компонентов современных информационных систем. Информационная система-это взаимосвязанная совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи информации.

Цель любой информационной системы - обработка информации конкретной предметной области.

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

База данных - это приложение, обеспечивающее создание, хранение, обновление и поиск информации в базе данных, а также управление безопасностью и целостностью данных. В простейшем случае - это программа, которая обеспечивает работу с информацией. Информация в базе может быть любая, при этом, как правило, работа с информацией подразумевает следующие действия:

добавление новой информации;

поиск информации;

изменение информации;

удаление информации из базы данных;

Мир программных систем, позволяющих использовать базы данных, довольно многообразен. В настоящее время существует достаточно большое количество программных систем, позволяющих создавать и использовать локальные и удаленные базы данных. Среди наиболее известных можно отметить Paradox, dВase, FoxPro, MS Access, InterBase, Oracle, Infomix, MS SQL Server и другие.

Тема курсового проекта: проектирование базы данных для магазина продовольственных товаров «Статус».

Название проекта: проектирование базы данных на примере ООО «Статус».

Цель проекта: создание базы данных, включающей детальное представление структуры данных, изучение работы выбранного предприятия, на основе созданной логической и реляционной модели, закрепление знаний и навыков, приобретаемых на лекционных и практических занятиях.

Основание проекта: создание модели и базы данных ИП ООО «Статус».

Используемые программные средства: Oracle SQL Developer Data Modeler, Oracle SQL Developer, СУБД Oracle 10gXE.



1. Анализ предметной области

1.1 Характеристика объекта исследования

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

Полное наименование: Общество с ограниченной ответственностью «Статус».

Юридический адрес: 662520, Россия, Красноярский край, пгт. Березовка, ул. Береговая-44.

Фактический адрес: 662520, Россия, Красноярский край, пгт. Березовка, ул. Береговая-44.

ИНН: 2404007245

КПП: 240401001

ОГРН: 1062404000592

Телефон: (39175) 2-14-37

Индивидуальный предприниматель: Янковская Т.В.

Деятельность ООО "СТАТУС"

Розничная торговля пищевыми продуктами, включая напитки, и табачными изделиями в специализированных магазинах

Розничная торговля фруктами, овощами и картофелем

Розничная торговля мясом, мясом птицы, продуктами и консервами из мяса и мяса птицы

Розничная торговля рыбой, ракообразными и моллюсками

Розничная торговля консервами из рыбы и морепродуктов

Розничная торговля хлебом, хлебобулочными и кондитерскими изделиями

Розничная торговля сахаристыми кондитерскими изделиями, включая шоколад

Розничная торговля мороженым и замороженными десертами

Розничная торговля алкогольными и другими напитками

Розничная торговля молочными продуктами и яйцами

Розничная торговля пищевыми маслами и жирами

Розничная торговля животными маслами и жирами

Розничная торговля растительными маслами

Розничная торговля мукой и макаронными изделиями

Розничная торговля крупами

Розничная торговля чаем, кофе, какао

Розничная торговля прочими пищевыми продуктами, не включенными в другие группировки;

Об организации:

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

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

Организационная структура:

Организационная структура определяет распределение ответственности и полномочий внутри организации. Структура предприятия устанавливается исходя из объёма и содержания задач, решаемых предприятием, направленности и интенсивности, сложившихся на предприятии информационных и документационных потоков, и с учётом его организационных и материальных возможностей.

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

Общая численность персонала: 14 человек.

1.2 Комплекс задач, решаемых объектом исследования

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

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

Автоматизация торговли в магазине имеет огромное количество плюсов:

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

2.Управлять магазином будет гораздо проще, так как все необходимые данные будут собраны в специальной товароучетной программе: остатки товара, выручка, оборачиваемость товаров и многое другое

3.Лояльность покупателей за счет скорости и качества предоставляемого обслуживания и систем различных скидок

4.Ценообразование - установленные программы упрощают процесс расчета цен, так как появляется возможность рассчитывать стоимость продажи, на основании стоимости закупок, также есть возможность автоматического округления.

В результате анализа комплекса задач выявлены следующие направления для модернизации:

Автоматизация торговли;

Расширение ассортимента товара;

Увеличение количества поставщиков;

Расширение торговой площади.



1.3 Текущий уровень использования информационных технологий объекта исследования

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

1.4 Обоснование необходимости модернизации информационных технологий объекта исследования и предложения по модернизации информационных технологий

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

Если говорить, непосредственно, о самой модернизации, то основными требованиями при выборе оборудования и программного обеспечения становятся следующие: экономичность, надежность и функциональность. В такой ситуации нужно исходить из принципа разумной достаточности. Магазин малой торговой площади не может иметь много кассовых рабочих мест для обслуживания покупателей, поэтому кассовое место должно быть максимально удобным и функциональным. Поскольку торговая площадь ООО «Статус» около 100 кв.м.- рекомендуемый стандарт 1 кассовый узел (для продуктового магазина).

В магазинах любого формата и специализации автоматизацию можно условно разделить на две части:

фронт-офис (программное обеспечение и ИТ-оборудование для торгового зала)

бэк-офис (программное обеспечение и ИТ-оборудование для главных отделов магазина, где работает администрация: директор, бухгалтерия, товаровед, кладовщик и т. д.)

1. Бэк-офис (Back Office) - программы для товароучета (приход, расход, списание товаров, проведение инвентаризации и т.д.)

Для продуктового магазина "шаговой доступности" , каковым является ООО «Статус», хорошим решением будет программное обеспечение "ШТРИХ-М" - надежное, удобное и недорогое, работающее на платформе "1С: Предприятие".

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

Ниже приведенные программы смогут не только оперативно автоматизировать работу сотрудников, но и помогут избежать погрешностей в подсчете и утере данных.

"ШТРИХ-М: Торговое предприятие v.4" - программа для оперативного учета на платформе "1С: Предприятие 7.7"

"ШТРИХ-М: Торговое предприятие v.5" - современное решение для управленческого учета на платформе "1С: Предприятие 8"

2. Фронт-офис (Front Office) - кассовые программы для учета продаж, устанавливаются на рабочие места кассиров:

"ШТРИХ-М: Кассир v.1/ v.2" - специализированное решение для магазинов проверенное временем, обладающее широкими функциональными возможностями

"ШТРИХ-М: Кассир v.5" - новое специализированное решение для магазинов на платформе "1С: Предприятие 8"

"ШТРИХ-М: РМК 6" - является принципиально новым бесплатформенным универсальным решением.

Функциональные возможности

Ведение партионного учета остатков товаров на складах предприятия и в торговых залах

Учет стоимости товаров ведется в закупочных ценах, а на розничных складах также и в розничных ценах

Списание товаров выполняется по одному из методов FIFO, LIFO, по среднему - в зависимости от настроек конфигурации

Реализация основных этапов товародвижения:

Поступление и возврат товаров поставщикам

Перемещение товаров между складами, инвентаризация, перевод товаров в некондицию

Ценообразование и переоценка товаров, включая автоматическую переоценку при поступлении товара на склад по новой розничной цене

Реализация товаров оптом и в розницу, возвраты от покупателей

Учет специфики розничной торговли и т.д.

При выборе ИТ-оборудования (кассовой техники, весов, оборудования штрих-кодирования) имеет значение специализация магазина, и главное - его проходимость, а, следовательно, нагрузка на кассовый узел. Поэтому очень важно правильно выбрать кассовую технику.

Рекомендуются также POS-системы с сенсорным экраном - они особенно хорошо подходят для элегантных бутиков, но в последнее время их все чаще выбирают магазины самых разных форматов. Причина - в удобном экранном интерфейсе, а также возможности сэкономить рабочее пространство (для такой POS-системы не нужна клавиатура). По своим возможностям они подойдут для магазина любого типа и формата. Могут быть укомплектованы любым фискальным регистратором "ШТРИХ-М": "ШТРИХ-LIGHT-ФР-К", "ШТРИХ-М-ФР-К" или "ШТРИХ-МИНИ-ФР-К" и т. д. (фискальный регистратор выбирается исходя из нагрузки на кассовый узел).

Примерные расходы:

ПК - 8000 монитор - 7000 ибп (источник бесперебойного питания) - 3000

сканер - 5000

фискальный регистратор - 25000

принтер этикеток - 15000

принтер лазерный (мфу) - 8000
весы с печатью - 25000

1.5 Выбор методов и средств решения задач, подлежащих автоматизации

В качестве среды разработки была выбрана СУБД Oracle Database 10g Express Edition, язык PL/SQL.

Для визуального моделирования ER-моделей, генерации схем данных, реверс-инжиниринга баз данных, разработки логической модели в нотациях Бахмана и Баркера, а также реляционной модели была выбрана расширенная версия SQL Developer- SQL Developer Data Modeler(ERwin).

Также использовлся язык Borland Delphi 7 - средство разработки приложений на основе объектно-ориентированного программирования (инструмент для реализации оконно-графического приложения для удобства работы пользователя с базой данных. Позволяет просматривать, а также осуществлять различные операции над таблицами, хранящимися в БД).

1.6 Определение общих требований к проектируемой системе

К любой проектируемой системе должны предъявляться определенные требования, которые будут удовлетворять запросы, как руководства, так и клиентов данной системы.

К проектируемой системе ООО «Статус» должны предъявляться следующие требования:

состав работников предприятия;

перечень видового состава продукции;

сбор заявок;

даты поставки товара;

количество поставщиков;

ежемесячная отчетность;

формирование счетов-фактур;

автоматизация системы;

удобный интерфейс;

актуальность данных;

эффективность работы;

надежная защита.



2. Проектирование программных средств информационной системы

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

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

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

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

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

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

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

Реляционная модель данных включает следующие компоненты:

Структурный аспект (составляющая) -- данные в базе данных представляют собой набор отношений.

Аспект (составляющая) целостности -- отношения (таблицы) отвечают определенным условиям целостности. РМД поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных.

Аспект (составляющая) обработки (манипулирования) -- РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное исчисление).

Рассмотрим основные операции над отношениями, которые могут представлять интерес с точки зрения извлечения данных из реляционных таблиц. Это объединение, пересечение, разность, расширенное декартово произведение отношений, а также специальные операции над отношениями: выборка, проекция и соединение.

Операция выборки - построение горизонтального подмножества, т.е. подмножества кортежей, обладающих заданными свойствами.

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

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

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

Объединение (UNION) отношений можно получить в результате их конкатенации с образованием одного отношения с исключением кортежей-дубликатов. При этом отношения должны быть совместимы, т.е. иметь одинаковое количество полей с совпадающими типами данных. Иначе говоря, отношения должны быть совместимы по объединению.

Операция пересечения (INTERSECT) RS=R-(R-S) определяет отношение, которое содержит кортежи, присутствующие как в отношении R, так и в отношении S. Отношения R и S должны быть совместимы по объединению.

Разность (EXCEPT) R-S двух отношений R и S состоит из кортежей, которые имеются в отношении R, но отсутствуют в отношении S. Причем отношения R и S должны быть совместимы по объединению.

Результат операции деления R:S - набор кортежей отношения R, определенных на множестве атрибутов C, которые соответствуют комбинации всех кортежей отношения S.

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

все данные на концептуальном уровне представляются в виде упорядоченной организации, определенной в виде строк и столбцов и называемой отношением (relation). Более распространенный синоним слова "отношение" - таблица (или "набор записей", или набор результатов - result set. Именно от этого и происходит термин "реляционные базы данных", а вовсе не от отношений между таблицами;

все значения являются скалярами. Это значит, что для любой строки и столбца любого отношения существует одно и только одно значение;

все операции выполняются над целым отношением и результатом этих операций также является целое отношение. Этот принцип называется замыканием. Поэтому результаты одной операции (например, запроса), можно использовать в качестве исходных данных для выполнения другой операции (подзапроса).

2.1 Декомпозиция проектируемой системы

Проектируемая система должна включать систему ввода данных, которая должна включать: модуль приветствия, авторизации (в БД реализован в виде таблицы, где запрашивается логин пользователя и пароль), аутентификации, главного меню, модуль окон просмотра и редактирования таблиц. Подсистема ввода реализуется в среде объектно-ориентированного языка программирования Borland Delphi 7.0.

Подсистема хранения включает в себя представление проектируемой БД в виде ER-диаграмм (логическая в нотациях Бахмана и Баркера, реляционная) с первичными, внешними и составными ключами, а также различными связями (один-к-одному, один-ко-многим, многие-ко-многим). Реализуется в среде SQL Developer Data Modeler.

Подсистема обработки так же, как и подсистема ввода, реализуется в среде объектно-ориентированного языка программирования Borland Delphi 7.0.

Она включает в себя следующие операции над таблицами:

добавление данных;

сортировка;

поиск информации;

выборка;

удаление.

Подсистема вывода содержит данные о пользователях в разделе справочник. В разделе реализуется система просмотра данных о сотрудниках, входящих в проектируемую БД. При желании можно редактировать некоторые пункты раздела, но при учете того, что пользователь обладает правами авторизованного пользователя. Реализуется в среде Borland Delphi 7.0.

2.2 Определение состава и назначения подсистем проектируемой информационной системы

Подсистема ввода:



Подсистема хранения- содержит таблицы с атрибутами, связями и ключами проектируемой БД:



Подсистема обработки предприятия ООО «Статус» осуществляет функции обработки данных, таких как:

выборка данных о сотрудниках, продажах, поставщиках, товарах, заказах;

редактирование данных о сотрудниках, продажах, поставщиках, товарах, заказах;

сортировка данных по сотрудникам, продажам, поставщикам, товарам, заказам;

добавление данных о сотрудниках, заказчиках, поставщиках, технике, продукции, заказах и поставках;

удаление данных о сотрудниках, продажах, поставщиках, товарах, заказах.

Подсистема вывода- хранит данные о предприятии в разделе «справочник»

Подсистема вывода ООО «Статус» осуществляет:

вывод справочника и информации о сотрудниках;

вывод справочника и информации о продажах;

вывод справочника и информации о поставщиках;

вывод справочника и информации о товарах;

вывод операции и информации о заказах;

2.3 Проектирование и реализация подсистем

Этапы физической реализации проектируемой базы данных

1.Концептуальное (инфологическое) проектирование построение формализованной модели предметной области. Такая модель строится с использованием стандартных языковых средств, обычно графических, например ER-диаграмм. Такая модель строится без ориентации на какую-либо конкретную СУБД.

Основные элементы данной модели:

Описание объектов предметной области и связей между ними.

Описание информационных потребностей пользователей (описание основных запросов к БД).

Описание алгоритмических зависимостей между данными.

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

2.Логическое (даталогическое) проектирование отображение инфологической модели на модель данных, используемую в конкретной СУБД, например на реляционную модель данных. Для реляционных СУБД даталогическая модель набор таблиц, обычно с указанием ключевых полей, связей между таблицами. Если инфологическая модель построена в виде ER-диаграмм (или других формализованных средств), то даталогическое проектирование представляет собой построение таблиц по определённым формализованным правилам, а также нормализацию этих таблиц. Этот этап может быть в значительной степени автоматизирован.

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

На этапе инфологического проектирования в ходе сбора информации о предметной области требуется выяснить:

основные объекты предметной области (объекты, о которых должна храниться информация в БД);

атрибуты объектов;

связи между объектами;

основные запросы к БД.

2.3.1 Проектирование и реализация подсистемы хранения

Сущность -нечто существуемое и различимое. Можно сказать, что под термином сущность понимается все, что может быть представлено в БД. Каждая сущность является множеством подобных индивидуальных

объектов, называемых экземплярами.

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

При разработке базы данных ООО «Статус» были выделены следующие сущности:

Сотрудник (продавец) - лицо, которое обслуживает покупателей магазина;

Поставщик - в данной фирме является лицом, поставляющим всю необходимую продукцию с базы в магазин;

Заказ - заявка в письменной форме, которая отражает список необходимых товаров, требующихся в магазин (заполняется продавцом и передается поставщику);

Товар - продукт труда, произведенный для продажи и, поставляемый поставщиком;

Продажа-итог работы продавца, подразумевающий покупку товара покупателем;

Поставка - этап передачи товара от поставщика к продавцу;

Товар Заказ- сущность, связывающая сущности Товар и Заказ

Продажа Сотрудник- сущность связывающая сущности Продажа и Сотрудник;

Сущность связывающая сущность Товар и Продажу- сущность Товар Продажа ;

Определение связей:

Связь-(relationship) - это функциональная зависимость между двумя

сущностями (возможна связь сущности с самой собой).

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

Сотрудник-Заказ: связь один-ко-многим(1:N Relation) ,один сотрудник может делать несколько заказов разным поставщикам;

Сотрудник-Продажа: связь многие-ко-могим(M:N Relation), каждый сотрудник может участвовать более, чем в одной продаже, а в каждой продаже может быть задействован более, чем один сотрудник;

Поставщик-Поставка: связь один-ко-могим (1:N Relation), один поставщик может осуществлять несколько поставок;

Поставщик-Заказ: связь один-ко-могим (1:N Relation), один поставщик может выполнять много заказов;

Товар-Заказ: связь многие-ко-многим (M:N Relation), несколько видов товара могут быть задействованы более, чем в одном заказе, а разные заказы могут включать множество видов товара

Товар-Поставка: связь один-ко-могим (1:N Relation), один вид товара может входить в состав различных поставок;

Товар-Продажа: связь многие-ко-могим(M:N Relation), каждый вид товара участвует более, чем в одной продаже, а в каждой продаже может быть задействован более, чем один товар;

Связь многие-ко-многим возможна только на уровне логической модели. При переходе к реляционной модели, должна быть произведена замена связи многие-ко-многим на один-ко-многим идентифицирующую (1:N Identifying Relation).

В результате такого преобразования создается новая таблица, называемая таблицей пересечения. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Таким образом связи Товар-Продажа, Сотрудник-Продажа и Товар-Заказ из связей многие-ко-многим переименуются в один-ко-многим и появятся три новые таблицы- ТоварПродажа, ПродажаСотрудник, ТоварЗаказ.

Определение первичных ключей:

Некоторые атрибуты сущности не только описывают, но и уникальным образом идентифицируют её. Их называют первичным ключом. Первичный ключ (primary key) - это атрибут или группа атрибутов, однозначно идентифицирующая экземпляр сущности.

Для того что стать первичным, потенциальный ключ должен удовлетворять ряду требований:

Уникальность - два экземпляра не должны иметь одинаковых значений возможного ключа.

Компактность - при выборе первичного ключа предпочтение должно отдаваться более простым ключам.

Атрибуты не должны содержать null-значений.

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

Первичными ключами базы данных ООО «Статус» будут следующие атрибуты:

для сущности Сотрудник- атрибут код сотрудника(суррогатный ключ);

для сущности Поставщик - атрибут код_поставщика (суррогатный ключ);

для сущности Поставка - атрибут код_поставки(суррогатный ключ);

для сущности Заказ - атрибут код_заказа (суррогатный ключ);

для сущности Товар - атрибут код товара (суррогатный ключ);

для сущности Продажа- атрибут код_продажи(суррогатный ключ);

для сущности ТоварПродажа - атрибут код_товар-продажа (суррогатный ключ);

для сущности ПродажаСотрудник - атрибут код_продажа-сотрудник(суррогатный ключ);

для сущности ТоварЗаказ - атрибут код товар-заказ(суррогатный ключ);

Определение атрибутов:

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

1) Определение атрибутов сущности Сотрудник: (код сотрудника,ФИО, опыт, адрес, номер телефона);

2) Определение атрибутов сущности Поставщик: (код поставщика, ФИО, фирма,телефон);

3) Определение атрибутов сущности Поставка: (код поставки, сумма, объем, дата поставки);

4) Определение атрибутов сущности Товар:(код товара, вид, торговая марка, закупочная цена, розничная цена, страна-производитель, срок годности, надбавка);

5) Определение атрибутов сущности Продажа:(код продажи, дата продажи, прибыль);

6) Определение атрибутов сущности Заказ:(код заказа, дата заказа, сумма, объем);

7) Определение атрибутов сущности ТоварПродажа:(код товар-продажа, код товара, код продажи);

8) Определение атрибутов сущности ПродажаСотрудник:(код продажа-сотрудник, код сотрудника, код продажи);

9) Определение атрибутов сущности ТоварЗаказ:(код товар-заказ, код товара, код заказа).

Построение ER-модели

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

Рис.1: Логическая модель в нотации Баркера

Рис.2: Логическая модель в нотации Бахмана

Рис.3: Реляционная модель данных

Проведение процесса нормализации и денормализации

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

1НФ. Отношение находится в первой нормальной форме тогда и только тогда, когда в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого из атрибутов. В реляционной модели отношение всегда находится в первой нормальной форме по определению понятия отношение. Что же касается таблиц в существующих реляционных СУБД (SQL-СУБД), то они могут не быть правильными отношениями и, соответственно, не находиться в 1NF.

Сущности Сотрудник, Поставщик, Заказ, Поставка, Товар, Продажа, ТоварПродажа, ПродажаСотрудник соответствуют 1НФ, так как:

имеют первичные ключи;

не имеют повторяющихся групп.

2НФ. Отношение находится во второй нормальной форме, если оно находится в первой нормальной форме, и при этом любой его атрибут, не входящий в состав потенциального ключа, функционально полно зависит от каждого возможного ключа. Функционально полная зависимость означает, что атрибут функционально зависит от всего составного потенциального ключа, но при этом не находится в функциональной зависимости от какой-либо из входящих в него частей. Или другими словами: в 2NF нет неключевых атрибутов, зависящих от части составного ключа.

Сущности Сотрудник, Поставщик, Заказ, Поставка, Товар, Продажа, ТоварПродажа, ПродажаСотрудник соответствуют 2НФ, так как:

представлены в 1НФ;

имеют простой первичный ключ.

3НФ. Согласно определению Кодда, таблица находится в 3НФ тогда и только тогда, когда выполняются следующие условия:

1) Отношение R (таблица) находится во второй нормальной форме;

2) Каждый непервичный атрибут R находится в нетранзитивной (то есть прямой) зависимости от каждого ключа R.

Таким образом, отношение находится в 3NF тогда и только тогда, когда оно находится во 2NF и отсутствуют транзитивные зависимости неключевых атрибутов от ключевых. Транзитивной зависимостью неключевых атрибутов от ключевых называется следующая: A > B и B > C, где A -- набор ключевых атрибутов (ключ), B и С -- различные множества неключевых атрибутов.

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

Сущности Сотрудник, Поставщик, Заказ, Поставка, Товар, Продажа, ТоварПродажа, ПродажаСотрудник соответствуют 3НФ, так как:

представлены в 2НФ;

между неключевыми атрибутами нет взаимосвязей.

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

Анализ целостности данных представленной модели Базы данных.

Обеспечение целостности данных гарантирует качество данных таблице.

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

Сущностная целостность

Доменная целостность

Ссылочная целостность

Пользовательская целостность

2.3.2 Проектирование и реализация подсистемы ввода

Подсистема ввода реализуется в среде объектно-ориентированного языка Borland Delphi 7.0.

Для автоматизированной информационной системы ООО «Статус» были разработаны:

Модуль авторизации и идентификации (UnitReg) появляется при запуске приложения и разрешает:

Вводить инициалы и пароль пользователя;

В случае прохождения авторизации пользователя появляется окно приветствия ООО «Статус»;

Затем появляется модуль главного меню. Модуль главного меню состоит из формы, где расположены пункты меню, в каждом пункте имеются подпункты для работы с приложением:

- Файл, содержится подпункт Выход - для выхода из приложения.

- Справочники, содержатся подпункты: Сотрудники, Продажи, Поставщики, Товары, Заказы):

- О программе, содержит подпункт с информацией о названии, версии программы и имени разработчика АИС:

На главной форме используются компоненты: Image - отображение картинки, MainMenu - создание главного меню и подпунктов.

2.3.3 Проектирование и реализация подсистемы вывода

Подсистема вывода содержит операции над работой с данными в разделе справочник, такие как: показ информации, изменение, добавление, удаление и сортировка информации.

На данной форме используются компоненты: Edit - для ввода текста, Button - кнопки для подтверждения или отмены , Label - отображение надписей (см. приложение 3).

ToolButton1 -кнопка добавления данных о сотруднике;

ToolButton2 - кнопка удаления данных о сотруднике;

ToolButton3 - кнопка изменения данных о сотруднике;

ToolButton4 - кнопка просмотра данных сотрудника;

ToolButton5 - кнопка сортировки данных о сотруднике;

PopupMenu - компонент, позволяющий выборку сортировки данных о сотруднике;

DBGrid1 - объект для отображения таблицы сотрудников.

Рис.1.Форма модуля для таблицы Сотрудники

Аналогичные кнопки с операциями, содержащимися в разделе справочник ,можно осуществлять и над остальными таблицами:

Рис.2.Форма модуля для таблицы Продажи

Рис.3.Форма модуля для таблицы Поставщики

Рис.4.Форма модуля для таблицы Товары

Рис.5.Форма модуля для таблицы Заказы

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

2.3.4 Подсистема обработки

С помощью функциональной структуры подсистемы обработки ООО «Статус» можно осуществить следующую обработку данных:

-сортировку данных;

-просмотр данных;

-добавление данных;

-изменение данных;

-удаление данных.

На форме присутствуют следующие элементы модуля:

Label1 - компонент, на котором расположена надпись «Номер сотрудника»;

Label2 - компонент, на котором расположена надпись «Фамилия»;

Label3 - компонент, на котором расположена надпись «Опыт»;

Label4 - компонент, на котором расположена надпись «Пароль»;

Label5 - компонент, на котором расположена надпись «Адрес»;

Label6 - компонент, на котором расположена надпись «Телефон»;

Label - компонент, на котором расположена надпись «Возраст»;

DBEdit1- компонент для отображения номера сотрудника;

DBEdit2- компонент для отображения фамилии, имени и отчества сотрудника;

DBEdit3 - компонент для отображения опыта работы сотрудника;

DBEdit4 - компонент для отображения адреса проживания сотрудника;

DBEdit5 - компонент для отображения даты рождения сотрудника;

DBEdit6- компонент для отображения телефона сотрудника;

DBEdit7- компонент для отображения телефона сотрудника

Button1 - кнопка «ОК;

Рис.6. Форма модуля данных сотрудника

Аналогичные компоненты для работы с данными присущи каждой таблице:

Рис.7.Форма модуля данных продажи

Рис.8.Форма модуля данных поставщика

Рис.9.Форма модуля данных товара

Рис.10.Форма модуля данных продажи



Заключение

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

На этапе проектирования была использована программа по разработке логических и реляционных моделей данных, с наглядным отражением атрибутов, входящих в систему работы реального предприятия- CASE-средство Oracle SQL Developer Data Modeler.

В ходе выполнения проекта была применима программа по созданию базы данных предприятия, включающая информационную часть содержания данных - Oracle SQL Developer. Совместно с ней было разработано автоматизированное приложение на платформе Borland Delphi 7.0.

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

Данное приложение должно обеспечивать:

Ввод, хранение, обработку и вывод необходимой информации;

Конфедициальность данных;

Защиту запрещенного доступа;

Подлинность и своевременность данных;

Мобильность доступа к необходимым данным;

Сподручный и понятный интерфейс;



Библиографический список

1. Архангельский А.Я.Программирование в Delphi 5 2-е изд., перераб. и дополн. -М.: ЗАО «издательство БИНОМ», 2000г. 1072с.

2.Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. - М.: Финансы и статистика, 2000. - 352 с.

3. Глушаков С.В., Ломотько Д.В. Базы данных: Учебный курс. -Харьков: Фашо; М.: ООО «Издательство АСТ», 2000. -504с.

4. Дейт К. Дж. Введение в системы баз данных: Пер. с англ. - Киев, М., СПб.: Изд. Дом «Вильямс», 1999. -848с.

5. Миндалёв И.В. Моделирование с помощью CASE -средства ERWIN за 8 дней: Учебное пособие / Краснояр. Гос. Аграрн. Ун-т. - Красноярск, 2001, -85с

6. Пейдж Вильям. Использование Oracle 8/8i. Специальное издание: пер. с англ. -М.: Издательский дом «Вильямс», 1999. -1024с.

7. Симонович С. В, Г. А Евсеев, А. Г Алексеев. Специальная информатика : Учебное пособие/ С. В Симонович, Г. А Евсеев, А. Г Алексеев. -М.: Аст-Пресс: Инфорком-Пресс, 2002, 400 с.

8.Фаронов В.В. Программирование баз данных в Delphi 7.0. Учебный курс-

СПб.: Питер, 2003.



Приложение 1

Создание таблиц БД ООО «Статус».:

create table Sotr(

kodsotr NUMBER NOT NULL ,

fio VARCHAR2 (35) ,

expir VARCHAR2 (10) ,

adr VARCHAR2 (30) ,

age VARCHAR2 (15) ,

tel NUMBER ,

primary key (kodsotr));

create table Postavchik (

kodpostavchika number NOT NULL ,

fio VARCHAR2 (35) ,

firm VARCHAR2 (20),

tel NUMBER ,

primary key (kodpostavchika));

create table Tovar (

kodtov NUMBER NOT NULL ,

vid VARCHAR2 (35) ,

torg_marka VARCHAR2 (45),

zakup_cena number,

rozn_cena number,

str_proizv VARCHAR2 (30),

srok_god VARCHAR2 (20) ,

nadbav VARCHAR2 (20) ,

primary key (kodtov ));

create table Prodaja (

kodprod NUMBER NOT NULL ,

data_prod VARCHAR2 (8) ,

profit VARCHAR2 (20) ,

primary key (kodprod));

create table Post (

kodpostavki NUMBER NOT NULL ,

kodtov number,

kodpostavchika number,

data_post VARCHAR2 (8) ,

summa VARCHAR2 (20) ,

volume VARCHAR2 (20) ,

primary key (kodpostavki),

foreign key(kodtov) references

Tovar,

foreign key(kodpostavchika) references

Postavchik);

create table Zakaz (

kodzakaz NUMBER NOT NULL ,

kodsotr number,

kodpostavki number,

data_zak VARCHAR2 (8) ,

summa VARCHAR2 (20) ,

volume VARCHAR2 (20) ,

primary key (kodzakaz) ,

foreign key (kodsotr) references

Sotr,

foreign key (kodpostavki)references Postavchik);

create table Prod_Sotr (

kodprodsotr number NOT NULL ,

kodprod number ,

kodsotr number ,

primary key (kodprodsotr),

foreign key(kodprod) references

Prodaja,

foreign key(kodsotr) references

Sotr);

create table Tov_Prod (

kodtovprod number NOT NULL ,

kodtov number ,

kodprod number ,

primary key(kodtovprod) ,

foreign key(kodtov) references

Tovar,

foreign key(kodprod) references

create table Tov_Zak (

kodtovzak number NOT NULL ,

kodtov number ,

kodzak number ,

primary key(kodtovzak) ,

foreign key(kodtov) references

Tovar,

foreign key(kodzak) references

Zakaz);

Prodaja);Заполнение данных в таблицы:

insert into Sotr values (1,'Облаева Т.В.','6 лет','ул.Пархоменко 12-3','42 года','21763');

insert into Sotr values (2,'Стюрьева Г.В.','3 года','ул.Весны 14-7','36 лет','21673');

insert into Sotr values (3,'Сорокина А.Г.','5 лет','ул.Мира 22-43','29 лет','21954');

insert into Sotr values (4,'Буряченко Ю.И.','7 лет','ул.Воронова 32-17','34 года','22644');

insert into Sotr values (5,'Плешакова Е.М.','2 года','ул.Пионерская 3-8','27 лет','27164');

insert into Sotr values (6,'Асташова О.А.','4 года','ул.Чкалова 21-16','32 года','23758');

insert into Sotr values (7,'Жигалова К.Ю.','6 лет','ул.Дружбы 1-12','35 лет','23691');

insert into Sotr values (8,'Юрьева Н.В.','3 года','ул.9 мая 15-18','30 лет','24267');

insert into Sotr values (9,'Волкова И.К.','8 лет','ул.Крупской 8-6','29 лет','21954');

insert into Sotr values (10,'Грачева С.Л.','5 лет','ул.Заводская 57-15','37 лет','21724');

insert into Postavchik values (1,'Вуккерт Ф.Ю.','Делси','29671');

insert into Postavchik values (2,'Милёхин А.А.','Троя','36955');

insert into Postavchik values (3,'Старков Б.Г.','Авангард','35742');

insert into Postavchik values (4,'Ермилов В.И.','Фаер','32921');

insert into Postavchik values (5,'Бекетов М.Л.','Авентин','25318');

insert into Postavchik values (6,'Ворничан Э.Е.','Лудинг','48912');

insert into Postavchik values (7,'Жаров К.С.','Прайм','37746');

insert into Postavchik values (8,'Прусов И.И.','Сибиряк','26385');

insert into Postavchik values (9,'Ларин П.Г.','Стар','45296');

insert into Postavchik values (10,'Янков Д.О.','Экор','28248');

insert into Tovar values (1,'Хлеб','Красноярский хлеб','14','16','Россия','48 часов','3процента');

insert into Tovar values (2,'Горбуша в банке','Синее море','30','35','Россия','3 года','4процента');

insert into Tovar values (3,'Орех мясной','Дымов','285','310','Украина','45 суток','6процентов');

insert into Tovar values (4,'Чай','Ахмад','28','33','Китай','1 год','4процента');

insert into Tovar values (5,'Кофе','Черная карта','180','202','Бразилия','3 года','4процента');

insert into Tovar values (6,'Шоколадная паста','Нутелла','73','77','Россия','96 часов','5процентов');

insert into Tovar values (7,'Спагетти','Макфа','13','18','Россия','2 года','4процента');

insert into Tovar values (8,'Шоколад','Бабаевский ','40','44','Украина','3 года','7процентов');

insert into Tovar values (9,'Сгущёнка','Простоквашино','39','45','Россия','3 года','6процентов');

insert into Tovar values (10,'Паштет грибной','Хамме','24','30','Германия','2 года','2процента');

insert into Prodaja values (1,'16.12','30000 тысяч');

insert into Prodaja values (2,'17.12','28000 тысяч');

insert into Prodaja values (3,'18.12','32000 тысячи');

insert into Prodaja values (4,'19.12','24000 тысячи');

insert into Prodaja values (5,'20.12','36000 тысяч');

insert into Prodaja values (6,'21.12','38000 тысяч');

insert into Prodaja values (7,'22.12','40000 тысяч');

insert into Prodaja values (8,'23.12','41000 тысяча');

insert into Prodaja values (9,'24.12','44000 тысячи');

insert into Prodaja values (10,'25.12','47000 тысяч');

insert into Post values (1,2,7,'14.12','18000','6 коробок');

insert into Post values (2,4,3,'11.12','22000','8 упаковок');

insert into Post values (3,6,10,'9.12','26000','7 ящиков');

insert into Post values (4,3,8,'15.12','31000','13 мешков');

insert into Post values (5,7,4,'13.12','18000','5 коробок');

insert into Post values (6,10,5,'19.12','24000','9 ящиков');

insert into Post values (7,8,3,'17.12','15000','4 упаковки');

insert into Post values (8,5,2,'18.12','21000','5 мешков');

insert into Post values (9,1,10,'12.12','17000','6 коробок');

insert into Post values (10,4,6,'20.12','35000','16 ящиков');

insert into Zakaz values (1,4,7,'11.12','22000','7 коробок');

insert into Zakaz values (2,3,9,'15.12','31000','13 мешков');

insert into Zakaz values (3,2,8,'14.12','18000','6 упаковок');

insert into Zakaz values (4,5,10,'12.12','17000','5 ящиков');

insert into Zakaz values (5,7,4,'19.12','24000','10 коробок');

insert into Zakaz values (6,8,6,'18.12','20000','6 мешков');

insert into Zakaz values (7,4,5,'13.12','19000','6 ящиков');

insert into Zakaz values (8,6,3,'9.12','25000','5 упаковок');

insert into Zakaz values (9,10,2,'20.12','34000','16 мешков');

insert into Zakaz values (10,9,8,'17.12','16000','6 коробок');

insert into Prod_Sotr values (1,2,3);

insert into Prod_Sotr values (2,5,6);

insert into Prod_Sotr values (3,7,8);

insert into Prod_Sotr values (4,9,10);

insert into Prod_Sotr values (5,8,2);

insert into Prod_Sotr values (6,4,9);

insert into Prod_Sotr values (7,1,4);

insert into Prod_Sotr values (8,3,7);

insert into Prod_Sotr values (9,6,5);

insert into Prod_Sotr values (10,10,1);

insert into Tov_Prod values (1,2,3);

insert into Tov_Prod values (2,5,6);

insert into Tov_Prod values (3,7,8);

insert into Tov_Prod values (4,9,10);

insert into Tov_Prod values (5,8,2);

insert into Tov_Prod values (6,4,9);

insert into Tov_Prod values (7,1,4);

insert into Tov_Prod values (8,3,7);

insert into Tov_Prod values (9,6,5);

insert into Tov_Prod values (10,10,1);

insert into Tov_Zak values (1,2,3);

insert into Tov_Zak values (2,5,6);

insert into Tov_Zak values (3,7,8);

insert into Tov_Zak values (5,9,10);

insert into Tov_Zak values (4,8,2);

insert into Tov_Zak values (7,4,9);

insert into Tov_Zak values (6,1,4);

insert into Tov_Zak values (8,3,7);

insert into Tov_Zak values (10,6,5);

insert into Tov_Zak values (9,10,1);

Простые и сложные запросы

1)вывести всю информацию о сотрудниках,при этом выводя их возраст в порядке возрастания.

select * from Sotr order by age ASC;

KODSOTR FIO EXPIR ADR AGE TEL

---------------------- ----------------------------------- ---------- ------------------------------ --------------- ----------------------

5 Плешакова Е.М. 2 года ул.Пионерская 3-8 27 лет 27164

9 Волкова И.К. 8 лет ул.Крупской 8-6 29 лет 21954

3 Сорокина А.Г. 5 лет ул.Мира 22-43 29 лет 21954

8 Юрьева Н.В. 3 года ул.9 мая 15-18 30 лет 24267

6 Асташова О.А. 4 года ул.Чкалова 21-16 32 года 23758

4 Буряченко Ю.И. 7 лет ул.Воронова 32-17 34 года 22644

7 Жигалова К.Ю. 6 лет ул.Дружбы 1-12 35 лет 23691

2 Стюрьева Г.В. 3 года ул.Весны 14-7 36 лет 21673

10 Грачева С.Л. 5 лет ул.Заводская 57-15 37 лет 21724

1 Облаева Т.В. 6 лет ул.Пархоменко 12-3 42 года 21763

10 rows selected

2)Вывести названия фирм,начинающихся на букву "А" или "С"

select firm from Postavchik where firm like 'А%' or firm like 'С%';

FIRM

--------------------

Авангард

Авентин

Сибиряк

Стар

4 rows selected