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

Северо-Осетинский Государственный Университет им. К.Л. Хетагурова

Отчет

по производственной практике в ООО "Зебра"

Подготовила:

студентка 5 курса

Туаева Е.П.

Руководитель:

Гамаонов В.Г.

Владикавказ 2013

Содержание

• Введение
• 1. Реляционная модель данных
• 2. Виды связей в БД
• 3. Постановка задачи
• 4. Структура таблиц
• 5. Связи в БД
• Заключение
• Список литературы

Введение

Полное официальное название рекламного агентства - "Группа компаний ООО "Зебра". "Зебра" оказывает всевозможные услуги в сфере рекламного бизнеса: полиграфия, организация промо - акций, размещение наружной рекламы, реклама на ТВ. Наиболее молодым и перспективным отделом в агентстве является отдел "Зебра-Мастер". Основным направлением деятельности "Зебра-Мастер" является полный комплекс услуг по изготовлению и размещению наружной рекламы в г. Владикавказ и других районах Республики Северная Осетия-Алания.

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

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

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

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

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

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

Введем понятия, необходимые для понимания процесса приведения модели к реляционной схеме.

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

Экземпляр отношения - совокупность значений свойств конкретного объекта.

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

Простой атрибут - атрибут, значения которого неделимы.

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

Требования к реляционным моделям

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

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

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

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

· При выполнении операций над данными не должно возникать трудностей.

Графическая интерпретация реляционной схемы

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

· Отношение представляется в виде полоски, содержащей имена всех атрибутов. Имя отношения пишется над ней.

· Первичный ключ отношения должен быть выделен жирной рамкой.

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

2. Виды связей в БД

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

Существует 4 типа связей:

1. "Один-к-одному" - любому экземпляру сущности А соответствует только один экземпляр сущности В, и наоборот.

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

2. "Один-ко-многим" - любому экземпляру сущности А соответствует 0, 1 или несколько экземпляров сущности В, но любому экземпляру сущности В соответствует только один экземпляр сущности А.

Ученику ставят много оценок; поставленная оценка принадлежит только одному ученику.

3. "Многие-к-одному" - любому экземпляру сущности А соответствует только один экземпляр сущности В, но любому экземпляру сущности В соответствует 0, 1 или несколько экземпляров сущности А.

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

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

Если при определении связи вам сложно выделить подчиненность, то вывод только один: вы плохо разобрались в предметной области.

4. "Многие-ко-многим" - любому экземпляру сущности А соответствует 0, 1 или несколько экземпляров сущности В, и любому экземпляру сущности В соответствует 0, 1 или несколько экземпляров сущности А.

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

3. Постановка задачи

Производственная практика была пройдена в ООО "Зебра" с 9 января 2013г. по 15 марта 2013г. Руководителем Центра была поставлена следующая задача:

- ознакомление с БД системы учета материалов на складе.

- знакомство со штатом машин, работающих с БД.

- разработка таблицы прихода материала на склад.

4. Структура таблиц

Таблица "Накладная"

Таблица "Поставщик"

Таблица "Склад"

Таблица "Кладовщик"

Таблица "Материал"

5. Связи в БД

Заключение

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

Список литературы

1. Бойко В.В., Савинков В.М. "Проектирование баз данных информационных систем". М.: Финансы и статистика, 1989.

Размещено на Allbest.ru