Okay, I'll bite, answers follow:

For our main project here, we have between 4 and 8 developers (it's
varied over the two and half years of the project). For many of the
smaller projects, I'm the analyst, the data architect, the developer,
etc.

For our main project, one of the developers is (somewhat arbitrarily)
the data architect. However, when a data model change is coming, what
tends to happen is that he, a couple of other developers, and usually
the analyst responsible for causing the change sit down for about an
hour and thrash out the new design. Sometimes we have to do this
several times until the new design settles.

Then, one of the developers is tasked with creating scripts for
performing the change (including any necessary data migration from the
existing system, or from new systems that we are replacing). Sometimes
these scripts are developed by a pair of developers working at a
single machine. If not, another developer is brought in at the end to
look over the scripts and spot any obvious goof ups. We strongly
discourage anyone from using automated tools and just trusting the
output.

Finally, the DBA schedules the scripts to be run at an agreed time,
after which the new structure is in place.

In general, it depends on how your organisation is structured, how big
your project is, whether you have to adhere to 101 standards or "just
get by", and so on.

Good luck,

Damien

Four.

As the DBA, I reserve the right to make all changes to the database. I
occasionally grant the developers permission to actually make changes, but
only if they ask me first. If I allow them to create tables, they must
submit the code to me first. Procedures, etc. are all up to them. I
generally allow them to create views, but because of the way the application
is accessed, security is not an issue.

What's a design process? <g>  Anyway, one particular developer is very good
at designing data, so we work together.

Do you want to know the way it is or the way it *should be* ?

I work in a very large company where each project team, either
small or large, is mostly autonomous as to how they handle
this issue.  I see the results of many project teams as part
of my work (only part of which is involves the schema and proposed
schema changes ... I also deal with performance, but that's
another issue.)  Project teams range in size from 6-8 "code
authors", to around 100 or so (not all of them working on
DBMS accesses, tho.)

On those projects where it has been "every man for himself", a disaster
has inevitably happened.  By disaster, I mean that the project
came to a screeching halt at some point in its life-cycle partly
because the schema had no underlying rhyme or reason (other than
that a developer decided to add a table for his/her convenience,
usually forgetting to add integrity constraints and such).
The result is an unmaintainable database and unmaintainable
code.[1]

Having (a team of) data architects is much better, since they,
at least, have some training and experience with actual
databases.  Your typical "coder" usually does not. (See
above about adding tables willy/nilly.) The smaller
development teams usually do not have data architects
but the more savvy ones go "down the hall" and ask for
advice from more experienced folks.  The result is a
more coherent and maintainable schema (and code).
This creates a sort-of ad-hoc data team which is
unofficially shared among many smaller projects.
(This needs management support and underestanding.
If Jane Doe is gonna donate her time to helping out
John Smith with his schema changes, management
needs to cut Jane some slack on her assignments.)

Involving the data team early-on is the best solution,
IMO.  By "early-on", I really mean "early-on", right
at the *requirements* phase [2].  But, as a minimum,
the data team should be involved during the initial
design phase.  The real data experts are usually
able to propose alternate schema designs which solve
the data problem better than the folks who have limited
data backgrounds.  Databases are not magic!  They take
careful design to get things right.  If the data
folks are not involved in the design phase, by the
time they *do* get involved there is already a vested
interest in a particular design and it's too late to
propose major design changes.

NPL

[1] - The most egregious example of this I have seen
was a project which was probably too successful.
The fist release was built for Customer_A.  Then
customers B, C, and D wanted *almost* the same
product.  Special tables were added for these
customers without any data analysis.  "Just get
it shipped quick!"  After they hit 9 or 10 customers,
their software maintenance costs were exceeding
their income. (10 different "schemas", 10 different
versions of the code, etc.)

[2] - (This is actually a minor soapbox, but I'll
expound anyway.)  In my company we have "customer
teams" which talk to the customer about the requirements
for the next release.  Some of these folks are also
loose cannons.  One example from recent memory:
"Oh sure, we can implement this requirement by adding
these 4 tables to the database, and what we'll do
is query each table in turn to see if it has the
matching data."  These *&^%#!*'s actually wrote that
implementation into the contract!  This constrained
the developers (who were not DBMS savvy) to that
implementation.  If they had consulted with a data
person early-on, it could have been solved in a much
simpler and efficient manner.  (See Sig for
more commentary.)